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Summary 


The Marshall Application Realignment System (MARS) Architecture project was established to meet the certification 
requirements of the Department of Defense Architecture Framework (DoDAF) V2.0 Federal Enterprise Architecture Certification 
(FEAC) Institute program and to provide added value to the Marshall Space Flight Center (MSFC) Application Portfolio 
Management process. 

The MARS Architecture aims to: (1) address the NASA MSFC Chief Information Officer (CIO) strategic initiative to improve 
Application Portfolio Management (APM) by optimizing investments and improving portfolio performance, and (2) develop a 
decision-aiding capability by which applications registered within the MSFC application portfolio can be analyzed and considered 
for retirement or decommission. 

The MARS Architecture describes a to-be target capability that supports application portfolio analysis against scoring measures 
(based on value) and overall portfolio performance objectives (based on enterprise needs and policies). This scoring and 
decision-aiding capability supports the process by which MSFC application investments are realigned or retired from the 
application portfolio. 

The MARS Architecture is a multi-phase effort to: 

(1) conduct strategic architecture planning and 
knowledge development based on the DoDAF V2.0 
six-step methodology, (2) describe one architecture 
through multiple viewpoints, (3) conduct portfolio 

AlAfc 4 A!*** | 1 | 

analyses based on a defined operational concept, 

and (4) enable a new capability to support the MSFC _ 

enterprise IT management mission, vision, and 
goals. 



This report documents Phase 1 (Strategy and 
Design), which includes discovery, planning, and 
development of initial architecture viewpoints. 

Phase 2 will move forward the process of building 
the architecture, widening the scope to include 
application realignment (in addition to application 
retirement), and validating the underlying 
architecture logic before moving into Phase 3. 
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The MARS Architecture key stakeholders are most interested in Phase 3 because this is where the data analysis, scoring, and 
recommendation capability is realized. Stakeholders want to see the benefits derived from reducing the steady-state application 
base and identify opportunities for portfolio performance improvement and application realignment. 

The authors approached the development of MARS Architecture viewpoints in stages. The first stage focused on the capability 
and operational viewpoints. The second stage focused on developing a high-level system viewpoint and the standards and 
guidance that apply to the MARS Architecture, as well as two additional capability and operational viewpoints. The third stage 
focused on mapping operational and system viewpoints to ensure integration and to expose additional viewpoints needed to 
more fully describe the architecture. 

Once the initial viewpoints were drafted, the authors revisited, refined, and "walked through" all viewpoint elements to ensure 
integration and referential integrity across viewpoints. The authors repeated these activities many times during the viewpoint 
development process - producing multiple iterations of each viewpoint. 

More viewpoints are needed to further describe the MARS Architecture. The authors plan to develop these additional 
viewpoints in Phase 2, and integrate them with the viewpoints developed thus far. 

The additional viewpoints provide information currently not represented in the existing viewpoints. This includes information 
about underlying data and data relationships; logic and business rules that underlie the concept of operations and behaviors; 
scenario and use case depictions; operational-to-system mappings; and performance measures. 

The authors discovered early on in the process the challenges presented by developing different views of one architecture; 
mainly, viewpoints cannot be developed sequentially or in isolation, and no viewpoint is ever finished due to the need for 
continual integration cross-checks and follow-through. 

The work presented in this report is representative of the work performed thus far to describe a target MARS Architecture. 
Future work will be documented as the MARS Architecture enters and exits each of the project review milestones described in 
this report. 

The authors will report findings and recommendations at the completion of the MARS Architecture project. 


About the authors: Andrea Belshe and Mandy Sutton are with Freedom Information Systems in Madison, AL. Ms. Belshe and Ms. 
Sutton are contractors on the Marshall Information Technology Services (MITS) contract at the NASA Marshall Space Flight 
Center (MSFC) near Huntsville, AL. Ms. Belshe and Ms. Sutton are members of the NASA MSFC Enterprise Architecture team in 
the MSFC Office of the Chief Information Officer (CIO). 
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1 Introduction 


1.1 About the Environment 

1.1.1 NASA 

The National Aeronautics and Space Administration (NASA) is an agency of the United States (US) government. NASA is 
responsible for the nation's civilian space program and aeronautics and aerospace research. The NASA mission is to "pioneer the 
future in space exploration, scientific discovery, and aeronautics research/ 7 

NASA was established by the National Aeronautics and Space Act on 29 July 1958, thereby replacing its predecessor, the 
National Advisory Committee for Aeronautics (NACA). The Agency became operational on 1 October 1958. Since then, NASA has 
led US efforts for space exploration such as the Apollo missions to the Moon, the Skylab space station, the International Space 
Station (ISS), and the Space Shuttle. 

Today, NASA conducts its work in four principal organizations called Mission Directorates: 

• Aeronautics - pioneers and proves new flight technologies that improve our ability to explore and which have practical 
applications on Earth. 

• Exploration Systems - creates capabilities for sustainable human and robotic exploration. 

• Science - explores the Earth, solar system, and universe beyond; charts the best route of discovery; and reaps the benefits 
of Earth and space exploration for society. 

• Space Operations - provides critical enabling technologies for much of the rest of NASA through the Space Shuttle, the 
International Space Station (ISS), and flight support. 

For more than 50 years, thousands of people have been working to answer these questions: What's out in space? How do we 
get there? What can we learn in space (and from trying to get there) that will improve life on Earth? The work continues. 

1.1.2 MSFC 

Marshall Space Flight Center (MSFC) is one of NASA's Centers and is located near Huntsville; AL. MSFC supports the design, 
development, and operation of space systems the United States (US) needs to journey into Low Earth Orbit (LEO) and beyond. 
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MSFC is the civilian rocketry and spacecraft propulsion research Center for the US government. MSFC was the original home of 
NASA, and today MSFC is NASA's lead Center for Space Shuttle propulsion and its external tank; payloads and related crew 
training; International Space Station (ISS) design and assembly; and computers, networks, and information management. 


MSFC supports the US space program in the following ways: 

• MSFC provides the multi-disciplined engineering expertise 
behind propulsion and transportation systems such as the 
Space Shuttle (Payload Operations Center) and the Ares 
rockets (Ares I and Ares V). 

• MSFC enables scientific discovery through development of 
hardware and instruments for projects including the Chandra 
X-ray Observatory, the GLAST Gamma-ray Burst Monitor, and 
Gravity Probe B. 

• MSFC develops, integrates, and operates major components 
and systems on the International Space Station (ISS) and 
supports its operations 24/7. 

• MSFC manages the Michoud Assembly Facility (MAF) in New 
Orleans, LA, which provides critical hardware components for 
the Space Shuttle. 



MSFC also contains the Huntsville Operations Support Center (HOSC), a facility that supports Space Shuttle launch payload and 
experiment activities at the Kennedy Space Center (KSC) and ISS launch and experiment operations. The HOSC also monitors 
rocket launches from Cape Canaveral Air Force Station when an MSFC payload is on board. 


1.1.3 Culture 

MSFC has a complex organizational reporting and decision-making hierarchy. MSFC also has multiple strategic entities, function 
capabilities, and sub-function activities that support Agency and Center business missions and the delivery of services and 
products to external and/or internal business stakeholders. 

MSFC has a diverse workforce with a complex mix of skills, professional backgrounds, designations, and reporting chains. The 
workforce includes people with general to highly specialized expertise in business, technology, and science; people with 
professional backgrounds in industry, the military, and civilian government; and designated civil servants, contractors, and other 
third-party service and product providers. 
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Any effort - especially an enterprise architecture effort - must align organizational culture, workforce culture, and social culture 
to balance business objectives, requirements, and cost; short-term needs, schedule imperatives, and strategic goals; mission 
safety, risk, and cost; and self interest, mutual interest, and collective actions with desired and "best'' outcomes. 

Cultural models might be helpful for the culture-to-desired outcome alignment need described above but architecture 
frameworks such as DoDAF V2.0 do not provide for a "culture viewpoint." As stated in the FEAC Institute DoD Architecture 
Framework 2.0 Guidebook: 

"This would assume technical, systems, and data are at the same level as culture. If on the other hand, we consider 
Zachman's primitives and each of the DoDAF products to be cultural artifacts we would search for the cultural as 
something that underlies the framework rather than is at the same level. This helps understand Melissa Cook (1997) 
finding how data is often managed in organizations is based on political and organizational culture matters rather than 
what an EA would discover makes the best sense for the enterprise." 

1.2 Background 

A portfolio is the collection of capabilities, resources, and related investments required to accomplish a mission-related or 
administrative outcome. Portfolio management activities include strategic planning, capital planning, governance, process 
improvement, performance measures, requirements generation, acquisition/development, and operations (from DoD 8115.02). 

The NASA strategy for Improving IT management provides an approach for IT portfolio management. The goal of the NASA IT 
application portfolio strategy is to leverage a portfolio view of existing IT application assets throughout NASA with the objective 
of improving the performance of the individual assets within the portfolio as well as the performance of the portfolio as a whole. 

The NASA approach for IT portfolio management involves establishing and governing an Application Portfolio Management 
(APM) framework that provides the ability to do the following: 

• Organize applications into relevant categories for decision making. 

• Consistently evaluate the relative importance and performance of steady-state applications. 

• Prioritize which assets require resources (people and dollars) in any given budget cycle. 

• Answer the question: What things should I spend money on/or apply management cycles to in this budget cycle? 

MSFC is a participating member of the NASA IT APM team working to implement and mature the framework for managing the 
application portfolio across the Agency. The Agency has defined four portfolios for IT applications: Science and Engineering 
applications, Project Management applications, Business Management applications, and IT Infrastructure applications. 

Each year, the MSFC Chief Information Officer (CIO) issues strategic initiatives. In 2010, the MSFC CIO issued a strategic initiative 
to improve MSFC Application Portfolio Management (APM) by optimizing investments in the application portfolio and improving 
portfolio performance. 
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1.3 Problem and Need 




MSFC has an established Application Portfolio Management (APM) process for 
initiating, assessing, prioritizing, and funding new application investments. This 
involves managing an investment "package" that includes a description of the 
investment, justification (with potential benefits), risk assessment, impact 
analysis, high-level requirements, proposed technical approach, lifecycle costs, 
investment scoring against predefined criteria, and a preliminary schedule. 

The problem is MSFC sustains and continues to add application investments to 
its application portfolio but many of these investments do not provide the 
business and technology value required to effectively and efficiently support 
business processes and meet NASA and MSFC strategic objectives. 

The MSFC APM process needs a capability by which new and existing 
investments can be assessed to ensure alignment with strategic goals, business 
objectives, and desired business outcomes. 

The capability would support the analysis and decision-making processes used to 
derive the recommendations for application portfolio corrections and 
adjustments that keep the portfolio optimally aligned. 


2 Architecture Intended Use 

2.1 Purpose 

The purpose of the Marshall Application Realignment System (MARS) Architecture is to: (1) address the NASA Marshall Space 
Flight Center (MSFC) CIO strategic initiative to improve Application Portfolio Management (APM) by optimizing investments and 
improving portfolio performance, and (2) develop a decision-aiding capability by which applications registered within the MSFC 
application portfolio can be analyzed and considered for retirement or decommission. 

The MARS Architecture project was established to meet the certification requirements of the Department of Defense 
Architecture Framework (DoDAF) V2.0 Federal Enterprise Architecture Certification (FEAC) Institute program and to provide 
added value to the MSFC Application Portfolio Management process. 
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2.2 Key Stakeholders 

The MARS Architecture has the following key stakeholders: 

• MSFC Chief Information Officer (CIO) 

• MSFC Planning, Policy, and Integration Office (PP&IO) 

• MSFC Enterprise Architecture Advisory Committee (MEAAC) 

• MSFC Application Portfolio Manager 

• MSFC Enterprise Architect (EA) 

• MSFC Responsible NASA Official (RNO) 

2.3 Questions Addressed 

The MARS Architecture addresses the following stakeholder questions: 

• How can MSFC consistently evaluate the relative importance and performance of steady-state applications? 

• How can MSFC reduce its overall application portfolio base, and thereby reduce future data center and infrastructure costs? 

• How can MSFC determine the extent of underused, unused, low business value, and/or low technology value applications in 
its application portfolio? 

• How can MSFC determine the extent of overlapping functionality within its application portfolio? 

• How can MSFC determine the cost to maintain an application in its application portfolio versus what it costs to retire or 
decommission it? 

• How can MSFC determine the extent of applications in its application portfolio that are still active past their target 
retirement dates? 
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2.4 Mapping of Stakeholder Questions to Stakeholders 

Table 1 lists the questions associated with the MARS Architecture key stakeholders. 

Table 1 Stakeholder Question to Stakeholder Mapping 

Stakeholder Issues 

MSFC CIO 

MSFC Planning, Policy, and 
Integration Office 

MEAAC 

MSFC Application Portfolio 
Manager 

MSFC Enterprise Architect 

Responsible NASA Official 

SQ-01: How can MSFC consistently evaluate the relative importance and performance of 
steady-state applications? 

X 

X 

X 




SQ-02: How can MSFC reduce its overall application portfolio base, and thereby reduce 
future data center and infrastructure costs? 

X 

X 

X 




SQ-03: How can MSFC determine the extent of underused, unused, low business value, 
and/or low technology value applications in its application portfolio? 



X 

X 

X 


SQ-04: How can MSFC determine the extent of overlapping functionality within its 
application portfolio? 



X 

X 

X 


SQ-05: How can MSFC determine the cost to maintain an application in its application 
portfolio versus what it costs to retire or decommission it? 



X 

X 

X 


SQ-06: How can MSFC determine the extent of applications in its application portfolio that 
are still active past their target retirement dates? 



X 

X 

X 

X 
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3 Architecture Scope 


3.1 Point of View 

The MARS Architecture is approached from the viewpoint of the MSFC Enterprise Architecture Advisory Committee (MEAAC), 
which is a key stakeholder for the MARS Architecture. 

The MEAAC directs, oversees, and approves the MSFC enterprise architecture design and operating configurations that affect 
MSFC IT investments in the MSFC IT portfolios. The MEAAC also reviews, approves, and controls changes to the baseline 
configuration of the MSFC enterprise architecture. 

3.2 Boundaries and Constraints 

3.2.1 Geographic Boundary 

The geographical scope of the MARS Architecture is the NASA Marshall Space Flight Center (MSFC) near Huntsville, AL. Although 
MSFC is geographically dispersed and has an organizational relationship with the Michoud Assembly Facility (MAF) in New 
Orleans, LA, the MARS Architecture is geographically focused only on MSFC near Huntsville, AL. 

3.2.2 Organizational Boundary 

The organizational scope of the MARS Architecture is the MSFC Office of the Chief Information Officer (CIO) organization 
hierarchy, mission Lines of Business (LOB), and sub-functions. 

3.2.3 Constraints 

The MARS Architecture includes the MSFC Application Portfolio Management (APM) process and all MSFC applications that are 
registered in the authorized MSFC Application Portfolio Management System (APMS). 

The MARS Architecture has the following constraints: 

• Focuses only on describing a new business capability, and not on introducing new technology. 

• Neither addresses nor applies to applications that are not registered in the APMS. 

• Does not include or address the process by which applications are registered in the APMS. 
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• Focuses only on applications that are in a sustaining/operational lifecycle state, as defined by the MSFC Application Portfolio 
Management process. 

• Focuses only on the operational application investments governed by NASA Procedural Regulation (NPR) 7120.7, NASA 
Information Technology and Institutional Infrastructure Program and Project Management Requirements. The MARS 
Architecture neither addresses nor applies to operational application investments governed by NPR 7120.5, NASA Space 
Flight Program and Project Management Requirements. 

Figure 1 shows the Application Portfolios addressed by the MARS Architecture and the applicable NASA guidance. 



Figure 1 MSFC Application Portfolios 

3.3 Architecture Timeframe 

The MARS Architecture describes "to-be" target architecture. 


MARS Architecture Practicum Report, rev-3 12 June 2010 Page 10 











4 Approach 

The MARS Architecture describes a to-be capability that supports application portfolio analysis against scoring measures (based 
on value) and overall portfolio performance objectives (based on enterprise needs and policies). This scoring and decision-aiding 
capability supports the process by which MSFC application investments are realigned or retired from the application portfolio. 

Score measures include: 

• Cost of operation and maintenance 

• Frequency of use 

• Mission alignment 

• Network use 

• Number of users 

• Primary functionality 

• Retirement target date 

• Risk rating 

• Security compliance 

• Years in use 

The approach is to focus on aligning the MSFC application portfolio based on desired business outcomes that are driven by 
strategic goals, objectives, and business requirements. 

4.1 Probable Analysis Methods 

The probable analysis methods for the MARS Architecture include business case analysis, trade-off analysis, and performance 
analysis. 

The MARS Architecture analysis method will likely use score measures to apply techniques such as Balanced Scorecard (BSC), 
Boston Consulting Group (BCG) or Boston matrix, and/or Growth-share matrix measurement and management. In Phase 2, 
which is outside the scope of this report, the MARS Architecture scoring logic will be modeled and the portfolio analysis 
approach will be derived. 
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5 Foundation 


5.1 Guidance and Standards 

5.1.1 Architecture Development Guidance 

To the extent possible and practical, the MARS Architecture will follow the guiding principles for architecture development 
suggested in DoDAF V2.0 Volume 1: Introduction , Overview , and Concepts Manger's Guide (May 2009) and the DoDAF V2.0 
Volume 2: Architecture Data and Models Architect's Guide (May 2009). 

5.1.2 Federal, NASA, and MSFC Guidance 

The Federal Government issues numerous directives, guidelines, laws, mandates, policies, procedures, regulations, 
requirements, rules, and standards that apply to the development and delivery of government-funded end products and 
services to citizens. These also provide information and guidance for managing strategic plans, justifying Information Technology 
(IT) expenditures, measuring IT performance, integrating new technologies, and managing information resources. In addition, 
the Federal Government has issued laws, policies, and guidance specifically to establish the importance of using architecture to 
support decision-making activities. 

NASA and MSFC also issue directives, guidelines, policies, procedures, requirements, and so forth to: (1) manage, develop, and 
deliver end products and services that support the Agency, Centers, and multiple lines of business, and (2) establish use of 
architecture to support decision-making activities. 

5.1.3 MARS Architecture Standards 

The Standards Profile (StdV-1) on page 96 lists the guidance and standards applicable to the MARS Architecture. 

5.2 Capability Context 

NASA defined core function areas that provide the capabilities to support its strategy to improve IT management at the Agency 
and Center levels. These include: 

1. Governance and Policy 

2. Enterprise Architecture 

3. IT Security 

4. Relationship Management 

5. Resource Management 
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6. Innovation Management 

7. Project Management 

8. Service Management and Delivery 

9. Performance Management 

Function areas 1 through 3 help ensure compliance with Federal law and Agency policy. Function areas 4 through 6 help ensure 
alignment with Center and Agency mission needs. Function areas 7 through 9 help ensure the ability of the IT organization to 
execute on product and service delivery. 

5.2.1 MSFC IT Management Mission 

In this context, the MSFC mission is to maintain an MSFC enterprise-wide IT investment portfolio in alignment with Agency, 
Center, and Program mission and business needs; and ensure proper management of investments within the portfolio. 

5.2.2 MSFC IT Management Vision 

The vision is to improve performance of new and existing application portfolio investments using a consistent analysis approach, 
relative scoring criteria, and decision-aiding intelligence to: (1) ensure optimal alignment with MSFC business and technical 
objectives, and (2) reduce the total number of steady-state applications in the MSFC application portfolio. 

5.2.3 Goals 

The IT portfolio management goals are: 

• Remove underused, unused, low business value, and low technology value applications. 

• Reduce duplicated and overlapping functionality. 

• Retire applications. 

5.2.4 Initiatives 

The MSFC CIO issues strategic initiatives each year. The 2010 initiative relative to the MARS Architecture is: "Improve MSFC 
Application Portfolio Management (APM) by optimizing investments in the application portfolio and improving portfolio 
performance." 
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5.2.5 Execution 

The MSFC Enterprise Architecture methodology focuses on conducting detailed architecture efforts for specific, prioritized 
architectural "segments." Segment architecture is a detailed architecture for a portion of the overall MSFC EA, where 
measurable results (performance improvement, cost reduction) can be achieved through implementation of an improved to-be 
target state. 

Segment architectures focus on the IT portfolios as defined by the CIO and managed by the MSFC CIO. Each segment 
architecture addresses all architectural layers, from strategy to technology. This provides documentation of the business 
requirements and processes that drive the technology assets managed in the different IT portfolios. Integrating Enterprise 
Architecture documentation with the active governance and management of IT portfolios ensures that technology decisions 
align with business priorities. 

5.3 Performance Measures 

The MARS Architecture may be considered successful if one or more of the following occur as a result of the architecture effort: 

• Adoption of the MARS capability into the MSFC Application Portfolio Management framework 

• Validation that the MARS capability facilitates the desired effect (reduce MSFC application investment costs and better align 
applications with MSFC business and technology objectives) 

• Tangible and deliverable MARS capability output (retire recommendation) that supports MSFC CIO objectives 

• Reduction in the total number of applications sustained in the MSFC application portfolio from approximately 500 to a 
significantly lower number. 

6 Initial Data Types Identified 

The DoDAF Metamodel (DM2), which is based on ontological foundations, establishes a meta-vocabulary and provides for 
taxonomy and ontology relationships. The authors used the DM2 to help determine the DoDAF-described views needed to 
describe the MARS Architecture based on the data elements required to support the architecture purpose and scope, and to 
answer the key stakeholder questions. 

The authors built an initial list of appropriate DoDAF views mapped to the DM2 data elements. This list contains the architecture 
data that must be collected, organized, correlated, and stored in the next phase of the MARS Architecture project. The authors 
will determine how to use this data to support the analysis. 
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The DM2 data elements are used consistently across MARS Architecture views to create an integrated architecture description. 
The following are initial DM2 data types for the MARS Architecture: 


• 

Activity 

• Guidance 

• 

Rules 

• 

Capability 

• Measure 

• 

Standard 

• 

Data 

• Organization 

• 

System 

• 

Desired Effect 

• Performer 

• 

Vision 



• Resource 




6.1 Mapping of Stakeholder Questions to Data Requirements and Architecture Viewpoints 

Table 2 shows a mapping of questions addressed by the MARS Architecture, key stakeholders, DoDAF V2.0 data types, and 
DoDAF V2.0 viewpoints. This mapping helps to "connect-the-dots" and ensures the intersection of data and purpose. 


Table 2 Question, Stakeholder, Data Type, and Viewpoint Mapping 


Stakeholder Question 

Key Stakeholders 

Data Types 

Viewpoints 

SQ-01: How can MSFC consistently evaluate the relative 
importance and performance of steady-state applications? 

• MSFC CIO 

• MSFC PP&I Office 

• MEAAC 

• Activity 

• Capability 

• Desired Effect 

• Guidance 

• Measure 

• Standard 

• Vision 

CV-l, CV-2, OV-1, 
StdV-1 

SQ-02: How can MSFC reduce its overall application portfolio base, 
and thereby reduce future data center and infrastructure costs? 

• MSFC CIO 

• MSFC PP&I Office 

• MEAAC 

• Activity 

• Capability 

• Desired Effect 

• Guidance 

• Measure 

• Standard 

• Vision 

CV-l, CV-2, OV-1, 
StdV-1 
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Stakeholder Question 

Key Stakeholders 

Data Types 

Viewpoints 

SQ-03: How can MSFC determine the extent of underused, 
unused, low business value, and/or low technology value 
applications in its application portfolio? 

• MEAAC 

• MSFC Application 
Portfolio Manager 

• MSFC EA 

• Activity 

• Capability 

• Data 

• Desired Effect 

• Guidance 

• Measure 

• Organization 

• Performer 

• Resource 

• Rules 

• Standard 

• System 

CV-2, CV-5, OV-2, OV-3, 
OV-4, OV-5a, OV-5b, 
SV-1, StdV-1 

SQ-04: How can MSFC determine the extent of overlapping 
functionality within its application portfolio? 

• MEAAC 

• MSFC Application 
Portfolio Manager 

• MSFC EA 

• Activity 

• Capability 

• Data 

• Desired Effect 

• Guidance 

• Measure 

• Organization 

• Performer 

• Resource 

• Rules 

• Standard 

• System 

CV-2, CV-5, OV-2, OV-3, 
OV-4, OV-5a, OV-5b, 
SV-1, StdV-1 
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Stakeholder Question 

Key Stakeholders 

Data Types 

Viewpoints 

SQ-05: How can MSFC determine the cost to maintain an 
application in its application portfolio versus what it costs to retire 
or decommission it? 

• MEAAC 

• MSFC Application 
Portfolio Manager 

• MSFC EA 

• Activity 

• Capability 

• Data 

• Desired Effect 

• Guidance 

• Measure 

• Organization 

• Performer 

• Resource 

• Rules 

• Standard 

• System 

CV-2, CV-5, OV-2, OV-3, 
OV-4, OV-5a, OV-5b, 
SV-1, StdV-1 

SQ-06: How can MSFC determine the extent of applications in its 
application portfolio that are still active past their target 
retirement dates? 

• MEAAC 

• MSFC Application 
Portfolio Manager 

• MSFC EA 

• MSFC RNO 

• Activity 

• Capability 

• Data 

• Desired Effect 

• Guidance 

• Measure 

• Organization 

• Performer 

• Resource 

• Rules 

• Standard 

• System 

CV-2, CV-5, OV-2, OV-3, 
OV-4, OV-5a, OV-5b, 
SV-1, StdV-1 
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7 Architecture Lifecycle 


The MARS Architecture is a multi-phase effort to: 

1. Conduct strategic architecture planning and knowledge development based on the DoDAF V2.0 six-step methodology 

2. Describe one architecture through multiple viewpoints 

3. Conduct portfolio analyses based on the operational concept 

4. Enable a new capability to support the MSFC enterprise IT management mission, vision, and goals 

7.1 Phase Roadmap 

Figure 2 shows the MARS Architecture phase roadmap. This report documents Phase 1 (Strategy and Design), which includes 
discovery and planning activities, and development of the initial MARS Architecture viewpoints. 

Phase 2 will move forward the process of building the architecture, widening the scope to include application realignment (in 
addition to application retirement), and validating the underlying architecture logic before moving into Phase 3. 

The MARS Architecture key stakeholders are most interested in Phase 3 because this is where the data analysis, scoring, and 
recommendation capability is realized. Stakeholders want to see the benefits derived from reducing the steady-state application 
base and identify opportunities for portfolio performance improvement and application realignment. 
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STRATEGY 


• Purpose 

• Need 

• Key Stakeholders 

• Questions Addressed 

• Approach 


1 

, . 


DESIGN 

i 

i 

BUILD & VAIDATE 


ANALYZE 

• Scope 

i 

i 

• Use Cases 


• Use Cases through Model 

• Viewpoint 

i 

i 

• Architecture Views 


• Output Validation 

• Boundaries and 

i 

i 

• Data Collection Approach 


• Recommendation 

Constraints 

i 

• Data Integrity Check 


Integrity 

• Foundation 

i 

i 

• Scoring Measures 


• MARS Capability "Tuning" 

• Context 

i 

i 

• Scoring Measure 


• Iterate 

• Performance Measures 

i 

i 

Values 



• Initial Data Types 

i 

• Scoring Rules 



• Initial Architecture Views 

i 

i 

i 

• Analysis Workflow Rules 




USE MARS 

• MSFC APM Framework 

• Ongoing Application 
Portfolio Analysis 

• Realignment and 
Retirement 
Recommendations 

• Capability 
Improvements 


GOVERNANCE 

• MARS Policies and 
Procedures 

• MSFC APM Compliance 

• Business integration 



Phase 1 
Jun 2010 



Phase 2 
Jul 2010 



Phase S 
Aug 2010 



Phase 4 
Oct 2010 



Figure 2 MARS Architecture Phase 1 though Phase 4 
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7.2 Architecture Reviews 

The phases shown in Figure 2 align loosely to the NASA-prescribed program and project reviews documented in NPR 7120.7: NASA 
Information Technology and Institutional Infrastructure Program and Project Management Requirements. These reviews offer an 
opportunity to add value to the architecture and to share knowledge by inviting key stakeholders and subject matter experts 
who can provide confirmation of the approach and/or recommend options. The reviews also offer an opportunity to organize, 
assess, and communicate critical data and information among providers, architects, and key stakeholders. 

The authors intend to execute the project review milestones prescribed in NPR 7120.7 as part of the MARS Architecture 
lifecycle. Table 3 shows a mapping of MARS Architecture phases to the project review milestones documented in NPR 7120.7. 


Table 3 Mapping of MARS Architecture Phases to NASA-prescribed Project Reviews 


Project Review 

MARS Architecture Phase 

Phase 1 

Phase 2 

Phase 3 

Phase 4 ( 

System Concept Review (SCR) 

X 




System Requirements Review (SRR) 

X 




Preliminary Design Review (PDR) 


X 



Critical Design Review (CDR) 



X 


Operational Readiness Review (ORR) 




X 


The System Concept Review (SCR) evaluates the scope, cost benefit analysis, and a recommended concept for the purpose of 
receiving approval to proceed to the next phase. It assesses the effect on the "as-is" and "to-be" enterprise architecture. 

The System Requirements Review (SRR) examines the functional, technical, performance, and security requirements, and 
ensures that requirements and the selected concept will satisfy the objectives. 

The Preliminary Design Review (PDR) demonstrates that the preliminary design meets requirements with acceptable risk and 
within the cost and schedule constraints, and establishes the basis for proceeding with detailed design. It confirms that the 
correct design option has been selected, interfaces have been identified, and verification methods have been described. 

The Critical Design Review (CDR) confirms that the maturity of the design is appropriate to support proceeding with 
implementation, that it was developed in conjunction with stakeholders, demonstrates that the design meets detailed 
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requirements, and identifies open design issues for the purpose of obtaining a decision to proceed with development and 
deployment. 

The Operational Readiness Review (ORR) determines that the project is ready to "go-live/' It confirms that requirements have 
been met; the functionality, performance, and security controls have been thoroughly tested; procedures are in place for 
operations; the users have been adequately trained; and, the organization responsible for operating and sustaining is ready to 
assume responsibility. 

8 Architecture Viewpoints 

8.1 Staged Development Process 

The authors approached the development of MARS Architecture viewpoints in stages. The first stage focused on the capability 
and operational viewpoints. Once the initial viewpoints were drafted, the authors revisited, refined, and "walked through" all 
viewpoint elements to ensure integration and referential integrity across viewpoints. 

The second stage focused on developing a high-level system viewpoint and the standards and guidance that applies to the MARS 
Architecture, as well as two additional capability and operational viewpoints. Once these viewpoints were drafted, the authors 
revisited, refined, and walked through all viewpoint elements again - iterating the viewpoints many times. 

The third stage focused on mapping operational and system viewpoints to ensure integration and to expose additional 
viewpoints needed to more fully describe the MARS Architecture. 

The authors discovered early on in the process the challenges presented by developing different views of one architecture; 
mainly, viewpoints cannot be developed sequentially or in isolation, and no viewpoint is ever finished due to the need for 
continual integration cross-checks and follow-through. 

Throughout the architecture viewpoint development process, the authors used the established MSFC EA team practices for 
configuration management, data stewardship, and repository management. The authors created architecture products using 
Adobe Acrobat and Microsoft Excel, PowerPoint, Visio, and Word. 

8.2 Viewpoint Build Order and Integration 

Figure 3 shows the order in which the authors built the initial set of MARS Architecture viewpoints, and depicts the relationships 
between viewpoints. These relationships drove the architecture element validation, walk through, and iteration process. 
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Figure 3 MARS Architecture View Build Order and Integration 


8.3 Future Viewpoint Elaboration 

Additional viewpoints are needed to further describe the MARS Architecture. The authors plan to develop these viewpoints in 
Phase 2, and integrate them with the viewpoints developed thus far. 

The additional viewpoints provide information currently not represented in the existing viewpoints. This includes information 
about underlying data and data relationships; logic and business rules that underlie the concept of operations and behaviors; 
scenario and use case depictions; operational-to-system mappings; and performance measures. 

The authors plan to add the following viewpoints to the MARS Architecture: 
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• Conceptual Data Model to represent high-level data concepts and their relationships (DIV-1) 

• Logical Data Model to document the data requirements and structural business process (activity) rules (DIV-2). 

• Operational Rules Model to describe activity (operational activity) and identify business rules that constrain operations 
(OV-6a). 

• Event-Trace Description to describe operational activity (activity) and trace actions in a scenario or sequence of events 
(OV-6c). 

• Capability to Operational Activities Mapping to show the required capabilities and the operational activities that those 
capabilities support (CV-6). 

• Operational Activity to Systems Function Traceability Matrix to map system functions (activities) back to operational 
activities (activities) (SV-5a). 

• Operational Activity to Systems Traceability Matrix to map systems back to capabilities or operational activities (activities) 
(SV-5b). 

As the architecture work progresses, more viewpoints may be added. 

The work presented in this report is representative of the work performed thus far to describe a target MARS Architecture. 

Future work will be documented as the MARS Architecture enters and exits each of the project review milestones described in 

this report. 
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Part 2 

MARS Architecture Viewpoints 
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9 About the Viewpoints 

This part of the report provides detailed information about the following MARS Architecture viewpoints: 

1. AV-1 - Overview and Summary Information 

2. CV-1 - Capability Vision 

3. OV-1 - High-level Operational Concept Graphic 

4. OV-5a - Operational Activity Decomposition 

5. OV-5b - Operational Activity Model 

6. OV-2 - Operational Resource Flow Description 

7. OV-3 - Operational Resource Flow Matrix 

8. SV-1 - System Interface Description 

9. OV-4 - Organizational Relationships Chart 

10. CV-2- Capability Taxonomy 

11. CV-5 - Capability to Organizational Development Mapping 

12. StdV-1 - Standards Profile 

13. AV-2 - Integrated Dictionary 

For readers unfamiliar with DoDAF V2.0, the authors provide a description, along with purpose and audience information for 
each viewpoint. The information is based on guidance provided in the DoD Architecture Framework Version 2.0 (DoDAF V2.0) 
Volume 2: Architectural Data and Models Architect's Guide. 

For readers familiar with DoDAF V2.0, the authors suggest skipping to the MARS Architecture-specific information provided for 
each viewpoint. This information includes tailoring applied, viewpoint, view discussion, view integration, and stakeholder 
questions addressed. 
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10 AV-1 Architecture Overview and Summary 

10.1 DoDAF-described AV-1 

10.1.1 Description 

The AV-1 Overview and Summary contains the written summary information that executives or decision makers use to review 
the architecture description. Architects use the AV-1 while developing the various viewpoints to remain consistent with the 
overall architecture and to frame the context for the development of the architecture description. 

The AV-1 provides to anyone reviewing the architecture description a quick reference point for the various viewpoints contained 
in the architecture, which allows a reviewer to quickly review the architecture and select a viewpoint for additional reading or 
research. The AV-1 includes assumptions, constraints, and limitations that may affect high-level decisions relating to the review 
and approval of the architecture. The AV-1 also includes a synopsis of findings, recommendations, and follow-up actions. 

10.1.2 Purpose 

The AV-1 servers as a planning guide in the initial phases of architecture development. Once the architecture description has 
been approved by the decision maker, the AV-1 provides the roadmap for the actual implementation of the architecture. It 
provides summary information concerning who, what, when, why, and how of the plan as well as a navigation aid to the 
viewpoints and models that have been created for the designers to use for implementation. 

The AV-1 is used to: 

• Define and scope the architecture effort 

• Provide context to the architecture effort 

• Summarize the findings from the architecture effort 

• Assist search within an architecture repository 

10.1.3 Audience 

The AV-1 audience includes: 

• Architecture sponsors 

• Architecture participants 

• Architecture stakeholders 

• Architecture development team 

• Architecture repositories 
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10.2 MARS Architecture AV-1 

10.2.1 Tailoring Applied 

The authors did not tailor the MARS AV-1. 

10.2.2 Viewpoint 

The viewpoint of the MARS AV-1 is the MEAAC. 

10.2.3 View Discussion 

The MARS AV-1 provides a quick reference and high-level overview of the Marshall Application Realignment System (MARS) 
Architecture. The MARS AV-1 includes information derived primarily from Steps 1 through 3 of the DoDAF V2.0 methodology. In 
a future version, the MARS AV-1 will also include a synopsis of MARS Architecture outcomes such as findings, recommendations, 
and opportunities for future work. 

The authors will update the MARS AV-1 as the project progresses to ensure alignment between planned and actual architectural 
development. The authors will also complete the "Findings" section of the AV-1 after the project has been completed. 

10.2.4 View Integration 

The MARS AV-1 drives content and data elements for all of the MARS Architecture viewpoints. Likewise, all MARS Architecture 
viewpoint content and data elements must align with and validate against the MARS AV-1 content. For example, the MARS AV-1 
is a written description of the architecture depicted in the MARS OV-1 High-level Operational Concept Graphic. 

10.2.5 Stakeholder Questions Addressed 

All stakeholders may refer to the MARS AV-1 for information about the MARS Architecture. The MARS AV-1 was not developed 
to address specific stakeholder questions but to address the purpose, scope, context, and overall architecture description. 
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Figure 4 MARS Architecture AV-1 Architecture Overview and Summary 

Date: 12 June 2010 MARS Architecture AV-1 Architecture Overview and Summary MARS-01 

Architecture Project Identification 

Name: Marshall Application Realignment System (MARS) Architecture 
Architects: (in alphabetic order) Andrea Belshe and Mandy Sutton 

Organization Developing the Architecture: National Aeronautics and Space Administration (NASA) Marshall Space Flight Center (MSFC) 

Assumptions and Constraints: The MARS Architecture project was established to meet the certification requirements of the Department of 
Defense Architecture Framework (DoDAF) V2.0 Federal Enterprise Architecture Certification (FEAC) Institute program and to provide added 
value to the MSFC Application Portfolio Management (APM) process. This MARS Architecture project encompasses Phase 1 activity only and 
must be completed by 14 June 2010. High-level schedules for MARS Architecture project Phase 2 and beyond will be determined at the 
completion of Phase 1. 

Approval Authority: MARS Architecture management team and Marshall Enterprise Architecture Advisory Committee (MEAAC) 

Date Completed: The MARS Architecture project is in progress (Phase 1 completion target is 14 June 2010). 

Level of Effort and Projected and Actual Costs to Develop the Architecture: The MARS Architecture project has limited allocated resources. 
The MARS Architecture project team consists of two architects. The MARS Architecture management team provides requirements, direction, 
and guidance as needed. Stakeholder organizations provide subject matter expertise, review input and feedback, facilities, materials, and 
access to systems as needed. Specific budget and cost information must be requested from the MSFC Financial Services organization due to 
its sensitive content. 
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Date: 12 June 2010 MARS Architecture AV-1 Architecture Overview and Summary MARS-01 

Scope, Architecture Viewpoints, and Artifact Identification 

Viewpoints and Artifacts Developed: The MARS Architecture project provides the following core DoDAF V2.0 viewpoints: 

• AV-1 - Overview and Summary Information 

• AV-2 - Integrated Dictionary 

• OV-1 - High-level Operational Concept Graphic 

• OV-2 - Operational Resource Flow Description 

• OV-3 - Operational Resource Flow Matrix 

• OV-5a - Operational Activity Decomposition 

• OV-5b - Operational Activity Model 

• SV-1 - System Interface Description 

• StdV-1 - Standards Profile 

The MARS Architecture project provides the following supporting DoDAF V2.0 viewpoints: 

• CV1 - Capability Vision 

• CV-2 - Capability Taxonomy 

• CV-5 - Capability to Organizational Development Mapping 

• OV-4 - Organizational Relationships Chart 

Timeframe Addressed: The MARS Architecture timeframe is a To-be capability. 

Organizations Involved: The MSFC Office of the Chief Information Officer (CIO) organization hierarchy, mission Lines of Business (LOB), and sub- 
functions. 

Purpose and Viewpoint: 

Background: The NASA strategy for Improving IT management at provides an approach for IT portfolio management. The goal of the IT 
application portfolio strategy is to leverage a portfolio view of existing IT application assets throughout NASA with the objective of improving 
the performance of the individual assets within the portfolio as well as the performance of the portfolio as a whole. 

The MSFC CIO issued a 2010 strategic initiative to improve MSFC Application Portfolio Management (APM) by optimizing investments in the 
application portfolio and improving portfolio performance. 

Need: MSFC has an established APM process for initiating, assessing, prioritizing, and funding new application investments. The problem is 
MSFC sustains and continues to add application investments to its application portfolio but many of these investments do not provide the 
business and technology value required to effectively and efficiently support business processes and meet NASA and MSFC strategic 
objectives. 

The MSFC APM process needs a capability by which new and existing investments can be assessed to ensure alignment with business and 
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Date: 12 June 2010 MARS Architecture AV-1 Architecture Overview and Summary MARS-01 

technology objectives. The capability would support the analysis and decision-making processes used to derive the recommendations for 
application portfolio corrections and adjustments that keep the portfolio optimally aligned. 

Approach: The MARS Architecture describes a to-be capability that supports application portfolio analysis against scoring measures (based on 
value) and overall portfolio performance objectives (based on enterprise needs and policies). This scoring and decision-aiding capability 
supports the process by which MSFC application investments are realigned or retired from the application portfolio. 

Scoring include: 

• Cost of operation and maintenance 

• Frequency of use 

• Mission alignment 

• Network use 

• Number of users 

• Primary functionality 

• Retirement target date 

• Risk rating 

• Security compliance 

• Years in use 

Probable Analysis Methods and Expected Outcome: The probable analysis methods for the MARS Architecture project include business case 
analysis, trade-off analysis, and performance. 

Enterprise Questions Addressed: The MARS Architecture project addresses the following stakeholder questions: 

• How can MSFC consistently evaluate the relative importance and performance of steady-state applications? 

• How can MSFC reduce its overall application portfolio base, and thereby reduce future data center and infrastructure costs? 

• How can MSFC determine the extent of underused, unused, low business value, and/or low technology value applications in its 

application portfolio? 

• How can MSFC determine the extent of overlapping functionality within its application portfolio? 

• How can MSFC determine the cost to maintain an application in its application portfolio versus what it costs to retire or decommission it? 

• How can MSFC determine the extent of applications in its application portfolio that are still active past their target retirement dates? 

Viewpoint: The MARS Architecture is developed from the perspective of the MEAAC. 

Boundaries: The MARS Architecture project scope includes the MSFC Application Portfolio Management (APM) process and all MSFC 
applications that are registered in the authorized MSFC Application Portfolio Management System (APMS). The MARS Architecture project 
has the following constraints: 
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Date: 12 June 2010 MARS Architecture AV-1 Architecture Overview and Summary MARS-01 

• Focuses only on describing a new business capability, and not on introducing new technology. 

• Neither addresses nor applies to applications that are not registered in the MSFC APMS. 

• Does not include or address the process by which applications are registered in the MSFC APMS. 

• Focuses only on applications that are in a sustaining/operational lifecycle state, as defined by the MSFC Application Portfolio 
Management process. 

• Focuses only on the operational application investments governed by NASA Procedural Regulation (NPR) 7120.7, NASA Information 
Technology and Institutional Infrastructure Program and Project Management Requirements. The project neither addresses nor applies 
to operational application investments governed by NPR 7120.5, NASA Space Flight Program and Project Management Requirements. 

Context 

Mission: Maintain a MSFC enterprise-wide IT investment portfolio in alignment with Agency, Center, and Program mission and business needs; 
and ensure proper management of investments within the portfolio. 

Vision: Improve performance of new and existing application portfolio investments using a consistent analysis approach, relative scoring criteria, 
and decision-aiding intelligence to: (1) ensure optimal alignment with MSFC business and technical objectives, and (2) reduce the total number of 
steady-state applications in the MSFC application portfolio. 

Goals: 

• Remove underused, unused, low business value, and low technology value applications. 

• Reduce duplicated and overlapping functionality. 

• Retire applications. 

Doctrine, Policy, and Guiding Principles: See MARS Architecture viewpoint StdV-1. 

File Formats and Tools Used 


• Adobe Acrobat (pdf) 

• Microsoft Excel (xlsx) 

• Microsoft PowerPoint (ppt) 

• Microsoft Visio (vsd) 

• Microsoft Word (docx) 

Findings 

Findings will be provided after the MARS Architecture project has been completed. 
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11 CV-1 Vision View 

11.1 DoDAF-Described CV-1 

11.1.1 Description 

The CV-1 Vision view defines the strategic context for a group of capabilities described in the architecture description by 
outlining the vision for a capability area over a bounded period of time. It describes how high-level goals and strategy are to be 
delivered in capability terms. Of key importance is the identification of goals, together with the desired outcomes and 
measurable benefits associated with them. 

11.1.2 Purpose 

The purpose of a CV-1 is to provide a strategic context for the capabilities described in the architecture description. It also 
provides a high-level scope for the architecture description that is more general than the scenario-based scope defined in an OV- 
1 . 

The intended use is communication of the strategic vision regarding capability development. Developing an architecture that 
includes the relationships necessary to enable a capability thread is essential to improving usability of architectures, as well as 
increasing the value of federation. 

11.1.3 Audience 

The CV-1 audience includes: 

• Architecture sponsors 

• Architecture stakeholders 

• Architecture development team 

11.2 MARS Architecture CV-1 

11.2.1 Tailoring Applied 

The authors "scoped down" the breadth of the MARS CV-1 to depict a piece of the whole CV-1 for NASA MSFC. The graphic 
depicts the one capability represented by MSFC Application Management (APM) and shows MSFC Application Scoring as a new 
capability within MSFC APM. This tailoring was practical because a full accounting of the MSFC or MSFC CIO enterprise 
capabilities was beyond the scope and time constraints of MARS Architecture Phase 1. 
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11.2.2 Viewpoint 

The viewpoint of the MARS CV-1 is the MEAAC. 

11.2.3 View Discussion 

The MARS CV-1 depicts the strategic context for the MARS Architecture. It includes the overall MSFC IT investment mission, 
vision, goals, desired effect, and the relationship of the MARS Architecture capability to the goals. The MARS CV-1 also includes 
the high-level activities in the MARS OV-5a and OV-5b views. 

1 1 .2.4 View Integration 

The MARS CV-1 set the high-level scope for the architecture description that was used to develop the remaining views. The 
MARS CV-1 was used along with the MARS AV-1 to define the MARS OV-1 that graphically depicts the textual AV-1 with the 
incorporation of the new MARS capability. The MARS CV-1 includes activities aligned with the MARS OV-5a and OV-5b. 

The MARS CV-1 was used to set the vision that was refined within the MARS CV-2 Capability Taxonomy view. 

1 1 .2.5 Stakeholder Questions Addressed 

• SQ-01 How can MSFC consistently evaluate the relative importance and performance of steady-state applications? 

• SQ-02 How can MSFC reduce its overall application portfolio base, and thereby reduce future data center and infrastructure 
costs? 
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12 OV-1 High-level Operational Concept Graphic 

12.1 DoDAF-Described OV-1 

12.1.1 Description 

The OV-1 High-level Operational Concept Graphic provides a graphical representation of the operational mission, concepts, 
scenario, functions, participants, organizations, and/or geographic locations of the architecture description. The graphic shows 
interactions between the architecture and its environment, and between the architecture and external systems. The OV-1 
depicts what the architecture is about and the operational players (performers) and operations involved. 

The OV-1 also provides the focus for future architecture discussion because it contains the key elements that are used within the 
architecture description. The graphic is accompanied with a textual description. 

12.1.2 Purpose 

The OV-1 purpose is to provide a quick, high level view of what the architecture is supposed to do by putting an operational 
situation or scenario into context for the decision makers and stakeholders of the architecture. 

The intended use is to: 

• Describes how the architecture accomplishes the objective 

• Convey simply, ideas about operational players and operations 

• Convey simply, geographical areas of operation 

• Provide a tool for discussion and presentation 

12.1.3 Audience 

The OV-1 audience includes: 

• Architecture sponsors/executives 

• Architecture stakeholders 

• Partners and external stakeholders 
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12.2 MARS Architecture OV-1 

12.2.1 Tailoring Applied 

The authors did not tailor the MARS OV-1. 

12.2.2 Viewpoint 

The viewpoint of the MARS OV-1 is the MEAAC. 

12.2.3 View Discussion 

The MARS OV-1 depicts the as-is situation and the to-be target capability that addresses the problem and need described in 
Problem and Need on page 6. The MARS OV-1 conceptualizes the MARS Architecture approach to derive the new capability by 
which MSFC application investments with low business value and low technology value can be identified and recommended for 
retirement, leaving the high business value and high technology value applications residing with the portfolios. The MARS OV-1 
frames the MARS operational concept and highlights interactions within the architecture and with other external systems. 

The key operational players (performers) that interact with the APM process and the APMS are shown on the graphic. The key 
operational players (performers) include: 

• MSFC CIO - Chief Information Officer for MSFC, responsible for all Information Technology (IT) within the Center 

• MSFC MEAAC - Responsible for reviewing and approving IT investments 

• MSFC Responsible NASA Official (RNO) - Manages the actual application that are listed within the application portfolios 

• MSFC Application Portfolio Managers - Manage the MSFC application portfolios 

• MSFC Stakeholder - Uses the applications listed within the application portfolios 

• MSFC EA - Responsible for Enterprise Architecture and Solutions Architecture for the Center. Supports the MEAAC with IT 
investment analysis. 

The MARS OV-1 depicts the approach to conduct a portfolio analysis against scoring measures (based on value) and overall 
portfolio performance objectives (based on enterprise needs and policies). The MARS OV-1 shows the high level activities from 
the MARS OV-5a, A1 Verify Metadata, A2 Analyze Data, and A3 Approve Retirement. See OV-5a Operational Activity 
Decomposition Tree View for additional details. 
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12.2.4 View Integration 

The high-level details of the operational concept depicted in the OV-1 are shown in the MARS OV-2, and the details of the 
information exchanged within the MARS OV-2 are documented in the MARS OV-3. See sections labeled OV-2 Operational 
Resource Flow Description View and OV-3 Operational Resource Flow Matrix View for additional details. The OV-1 also depicts 
the high-level operational activities depicted in the MARS OV-5a Operational Activity Decomposition Tree View. 


12.2.5 Stakeholder Questions Addressed 

• SQ-01 How can MSFC consistently evaluate the relative importance and performance of steady-state applications? 

• SQ-02 How can MSFC reduce its overall application portfolio base, and thereby reduce future data center and infrastructure 
costs? 
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MARS Architecture OV-1 High-Level Operational Concept Graphic 
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Figure 6 MARS OV-1 High-level Operational Concept Graphic 
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13 0V-5a Operational Activity Decomposition Tree View 

13.1 DoDAF-Described OV-5a 

13.1.1 Description 

The OV-5a Operational Activity Decomposition Tree view (with the OV-5b) describes the operations that are normally conducted 
in the course of achieving a mission or a business goal with a specific scenario. The OV-5a clearly delineates lines of 
responsibility for activities when coupled with OV-2. 

An operational activity is what work is required, specified independently of how it is carried out. To maintain this independence 
from implementation, logical activities and locations in OV-2 are used to represent the structure which carries out the 
operational activities. 

The OV-5a focuses on operational activities, whereas the OV-2 focuses on operational activities in relation to locations or logical 
interactions between operational players (performers). Due to the relationship between locations and operational activities, 
these types of views should normally be developed together. 

13.1.2 Product Guidance and Characteristics 

The OV-5a shows the activities depicted in a tree structure and is typically used to provide a navigation aid for the OV-5b. This 
diagram is sometimes referred to as a Node Tree Diagram. 

The OV-5a shows the hierarchical relationships among activities. The top box contains the overall activity of interest and is 
labeled AO. This overall activity is decomposed into sub-activities labeled Al, A2, A3, etc. These activities can be further 
decomposed if required to properly articulate the activities required to support the architecture. 

The OV-5a is usually presented in one of two forms. One uses a columnar arrangement of the activities. The other uses a more 
tree-like appearance. The choice of which style to use may be made by the architect and depends on the number of boxes - 
breadth and depth of the hierarchy - to be presented and the prevailing practice of the architecture team. 

Example Activity Hierarchy Diagram below shows the two formats in which an Activity Decomposition Tree is typically depicted. 
Both depictions show the same information but in different formats. 
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Figure 7 Example Activity Hierarchy Diagram 

13.1.3 Purpose 

The OV-5a purpose is to decompose the activities into the lowest level of decomposition necessary to properly depict the 
activities required to support the architecture description. The OV-5a diagram also provides the foundation of activity for other 
views and sets the boundaries for scope, purpose, and viewpoint. 

13.1.4 Audience 

The OV-5a audience includes business process managers who ensure that appropriate activities have been identified, or 
command and control personnel who confirm the operational activities. The audience also includes architects who use the 
OV-5a to create the OV-5b, which shows the activity and function details. 
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13.2 MARS Architecture 0V-5a 

13.2.1 Tailoring Applied 

The authors tailored the MARS 0V-5a by including the information exchanges identified within the activity description, which 
were later identified in the MARS OV-3. This integration was later added to the OV-5a to ensure the information exchanges tied 
back to the correct operational performers who were performing the operational activity information exchanges under the 
MARS Architecture. 

13.2.2 Viewpoint 

The viewpoint of the MARS OV-5a is the MEAAC. 

13.2.3 View Discussion 

The MARS OV-5a top-level activity is AO Retire Application. This top-level activity is composed of A1 Verify Metadata, A2 Analyze 
Data, and A3 Approve Retirement activities. 

• A1 Verify Metadata - this activity is decomposed into three sub-activities: Al.l Verify Metadata - RNO, A1.2 Verify Metadata - 
Application Portfolio Manager, and A1.3 Submit Application Portfolio Manager Metadata (IE7). 

o Al.l Verify Metadata - RNO. This activity is composed of the metadata verification process for the RNO metadata that is 
obtained from the APMS to ensure that the data is correct, before an assessment is conducted. Once verified, the metadata 
will be scored using the business score, retirement score, and technology score, depicted on the MARS CV-2. The scoring is 
performed within the organizations by the operational performers shown on the MARS OV-4 view. The MARS CV-2 is the 
taxonomy of the MARS CV-1 capability Application Scoring. 

o A1.2 Verify Metadata - Application Portfolio Manager. The activity is composed of the metadata verification process for 
the MSFC Application Portfolio Manager metadata. This activity verifies the metadata that will be used to produce the MARS 
CV-1 capability Application Scoring. The activity is decomposed on the MARS OV-5a to show the individual activities 
performed as part of the verification. 

o A1.3 Submit Application Portfolio Manager Metadata (IE7) - Activity describes the steps necessary to package the 

stakeholder verified metadata that will be used to produce the MARS CV-1 capability Application Scoring, is ready for the 
next activity. 

• A2 Analyze Data - is the activity where the actual analysis occurs and a retirement application listing is generated for review and 
final approval. The activity is decomposed on the MARS OV-5a to show the individual activities that is performed on the Stakeholder 
metadata for verification. 
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o A2.1 Conduct Assessment (IE5) - This activity is composed of the steps necessary to complete the summary assessment of 
the applications that are candidates for retirement. 

o A2.2 Conduct and Submit Initial Analysis (IE9) - Activity contains the necessary steps to conduct the deep dive analysis of 
the metadata to compile the information to create the list of applications for retirement, 
o A2.3 Review Initial Analysis (IE10) - This activity is the steps necessary for the MSFC Application Portfolio Manager to 
review the initial list of applications targeted for retirement to ensure that there is a valid list from the portfolio, 
o A2.4 Conduct and Submit Final Analysis (IE11) - The activity describes the final updates to the analysis that contains the list 
of applications that are targeted for retirements before submitting the analysis for review by the MEAAC. 

• A3 Approve Retirement - this is the activity where the initial retirement application listing is reviewed and formally approved, to 
initiate the actual retirement of the applications. The activity is decomposed on the MARS OV-5a to show the individual activities 
that are performs as part of their recommendation and approval of the list of applications targeted for retirement. 

o A3.1 Submit Retirement Recommendation (IE12) - Contains the activities necessary to review the analysis of potential 
applications targets for retirement before sending for approval, 
o A3. 2 Approve Recommendation (IE13) - Contains the activities where approval occurs against the list of potential 
applications targeted for retirement. 

o A3. 3 Initiate Retirement (IE14) - This activity is where the approved analysis that contains a list of application is 

communicated to the performer for action. The actual implementation of the retirement is out of scope for the MARS 
architecture. 

13.2.4 View Integration 

The MARS Architecture is integrated into the MARS OV-5b, which defines the interactions between the decomposed activities 
represented as functions on the OV-5b. The MARS Architecture is also dependent upon integration between the MARS CV-1 and 
the activities defined within the MARS OV-5a. The first level of OV-5a decomposition, shown in the diagram as A1 Verify 
Metadata, A2 Analyze Data, and A3 Approve Retirement, supports the new MARS CV-1 scoring capability. 

The node identifiers are used on MARS OV-3 by incorporating the node identifiers into the activity description. The MARS OV-5a 
node identifiers are also used on the MARS OV-2. 

This integration allows an architect to have full traceability between the MARS OV-2, the MARS OV-3, and their supporting 
activities previously defined within the MARS OV-5a. This gives the MARS Architecture a very tightly integrated operational 
viewpoint. 
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13.2.5 Stakeholder Questions Addressed 

• SQ-03 How can MSFC determine the extent of underused, unused, low business value, and/or low technology value 
applications in its application portfolio? 

• SQ-04 How can MSFC determine the extent of overlapping functionality within its application portfolio? 

• SQ-05 How can MSFC determine the cost to maintain an application in its application portfolio versus what it costs to retire 
or decommission it? 

• SQ-06 How can MSFC determine the extent of applications in its application portfolio that are still active past their target 
retirement dates? 
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Figure 8 MARS OV-5a Operational Activity Decomposition Tree 
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14 0V-5b Operational Activity Model View 

14.1 DoDAF-Described OV-5b 


14.1.1 Description 

The 0V-5b Operational Activity Model view describes the operational, business, and defense portion activities associated with 
the architecture description, as well as the relationships or dependencies among the activities, resource exchange between the 
activities, and external interchanges with activities outside of the architecture description. 

The OV-5b also describes input and output flows between activities, and to/from activities that are outside the scope of the 
architecture description. The OV-5b is expected to be used extensively for business modeling and can be depicted using 
techniques such as Business Process Modeling Notation (BPMN) swimlanes, Integration Definition for Function Modeling (IDEFO) 
models, or Unified Modeling Language (UML) Activity diagrams. (The authors chose the IDEFO modeling technique to develop 
the MARS OV-5bview.) 

14.1.2 Product Guidance and Characteristics 

The Context Diagram shown below establishes the bounds for the model and depicts the major Inputs, Controls, Outputs, and 
Mechanisms (ICOMS) used to perform the activity. The diagram consists of a single box and its related ICOMS. It sets the general 
context and scope of what is being modeled and displays the purpose and viewpoint of the model. This diagram is labeled A-0 (A 
minus 0). 

See figure labeled Example Context Diagram A-0 below that displays the example Context Diagram. 
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Figure 9 Example AO Context Diagram 
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Decomposition Diagram - This diagram describes the components of an activity and their relationships to one another. The 
diagram also shows the flow of ICOMs among activities. A decomposition diagram shows only one level of decomposition below 
its parent on each page. 

The first decomposition diagram of a model is labeled AO. The subsequent second level decomposition diagrams are labeled with 
the number of the box within AO that they refine, e.g., A1 or A3. Third-level decomposition labels could be, for example, All for 
a box that refines A1 or A31 for a box that refines A3. 

Using the IDEFO modeling standard, Federal Information Processing Standards (FIPS) Publication 183, boxes are arranged upper 
left to lower right within a page. The order of boxes on the page does not imply a sequence of operation, but the interface lines 
depict the sequence. The view should contain between three and six functions on a single page. Additional pages should be 
used to provide detail for the functions that are essential to the architecture description. 

The AO page text description emphasizes the interaction among the high-level activities performed. Lower level decomposition 
diagram pages text emphasizes the interactions between the activities and how the activities support each other. The text can 
address input, output, control, or mechanism issues, who are involved in performing the activity, anomalies, what could change 
a process that approves the outputs, or other aspects of interest. 

See figure labeled Example Decomposition Diagram of the A-0 Activity below to depict an example AO function. 
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Figure 10 Example A-0 Activity Decomposition Diagram 
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14.1.3 Purpose 

The OV-5b purpose is to depict critical activities as they are transforming inputs to outputs through activity sequences within the 
architecture. It also shows what operational performer is responsible for each activity, through the use of the activity 
mechanisms. The OV-5b provides the ability to perform redundancy analysis, streamlining activities, and reuse processes within 
architecture. It also provides the foundation of activity for other views and sets the boundaries for scope, purpose, and 
viewpoint. 


14.1.4 Audience 

The OV-5b audience includes: 

• Operational business process managers 

• Modeling and simulation personnel 

• Business process reengineering personnel 


14.2 MARS Architecture OV-5b 


14.2.1 Tailoring Applied 

The authors tailored the view by adding the MARS OV-5a node identifiers to each function's description. This allowed the 
authors to ensure referential integrity between the diagrams and to ensure the correct ICOMs were applied within the MARS 
OV-5b. 


14.2.2 Viewpoint 

The viewpoint of the MARS OV-5b is the MEAAC. 


14.2.3 View Discussion 

The MARS OV-5b view A-0 activity depicts relationships and dependencies among activities required to recommend applications 
for retirement to align the application portfolio by reducing the amount of applications within the portfolios that do not provide 
high business value and high technology value. 

Figure MARS A-0 Retire Application Context Diagram depicts the two inputs of As-ls Architecture and the As-ls Portfolio that 
exist today within the MFSC Center. The input labeled "As-ls Architecture" is labeled II on the decomposed diagrams. This input 
symbolizes the existing applications that reside within the four application portfolios that will be processed through the MARS 
architecture to reduce the overall number of applications. The second input labeled "As-ls Portfolio" is the existing application 
portfolio environment that contains redundant and under used applications. 
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The diagram also depicts the four controls that provide the overarching requirements and directives that govern the process 
that are listed in the MARS StdV-1. 

The eight mechanisms represent the operational performers and systems that support the process. The operational performers 
are presented within the MARS architecture in the section labeled OV-4 Organizational Relationships Chart View and the two 
systems (APMS and MSFC Email System) are presented in the MARS architecture in the section labeled SV-1 Systems Interface 
Description View. 

The single output of the Retire Application (AO) function is a realigned portfolio that has have the MARS scoring capability 
applied and the overall amount of applications reduced. 

See figure labeled MARS A-0 Retire Application Context Diagram below that depicts MARS A-0 Context Diagram. 
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PURPOSE: Depicts relationships and dependencies among activities required to recommend applications for 
retirement to realign the application portfolio. 

VIEWPOINT: MSFC MEAAC 

Tailoring: The OV-5a Operational Activity Decomposition Tree node identifiers have been included for 
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Figure 11 MARS A-0 Retire Application Context Diagram 
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The next view is a decomposition of the OV-5b A-0 function. The AO decomposed diagram shows the first level of relationships 
and dependencies required to recommend applications for retirement to realign the application portfolio and the information 
exchange between the activities within the Retire Application (AO) function. 

AO Diagram: The AO diagram has three child activities. Verify Metadata (Al), Analyze Data (A2), and Approve Retirement (A3) 
that compose the A-0 Retire Application parent function. The decomposed activities maintain the same set of controls that were 
previously defined within the parent function. The inputs, outputs, and mechanisms are described below with the decomposed 
functions. 

• Verify Metadata (Al) - The Verify Metadata (Al) function receives the two inputs II and 12, has the four controls, described above, 
that provide the guidance for this activity. The decomposed child functions for this activity are depicted in Al Verify Metadata (Al) 
child diagram. The output of this activity is verified application metadata, labeled output three (03). Output three (03) is the input 
for the next activity, Analyze Data (A2). The Verify Metadata (Al) function uses the MSFC Application Portfolio Manager (Ml), MSFC 
Stakeholder (M4), MSFC EA (M5), and MSFC RNO (M6) roles to verify the application metadata. All roles use the MSFC Email System 
(M8) to communicate the information exchanges. See section labeled Al Diagram Verify Metadata (Al) for additional details. 

• Analyze Data (A2) - The steps that compose the Analyze Data (A2) are detailed in the decomposed child diagram A2. The input for 
the function is the output from Verify Metadata (Al), which is Verified Application Metadata - 03. The decomposed child functions 
for this activity are depicted in A2 Analyze Data (A2) diagram. The output for the Analyze Data (A2) activity is Recommended 
Retirement Applications. This is input for the next activity Approve Retirement (A3). The Analyze Data (A2) function using the 
controls from the parent diagram A-0 Retire Application (AO). The mechanisms are the MSFC Application Portfolio Manager (Ml), 
and MSFC EA (M5) roles that all support the functions necessary to analyze the previously verified metadata to produce a list of 
recommended applications to retire. All roles use the MSFC Email System (M8) to communicate information exchanges. See section 
labeled A2 Diagram A2 Analyze Data (A2J for additional details. 

• Approve Retirement (A3) - The steps that compose the Approve Retirement (A3) are detailed in the decomposed child diagram A3. 
The final output for the parent process A-0 is shown on the AO diagram again, Realigned Portfolio, 01. The input for this function is 
the output from Analyze Data (A2), Recommended Retirement Applications - 04. The mechanisms are the MSFC CIO (M2), MSFC 
MEAAC (M3), and MSFC RNO (M6) roles that all support the approval of the recommended list of applications, and the 
implementation of the retiring applications. All roles use the MSFC Email System (M8) to communicate information exchange. The 
APMS system also supports this function. See the child diagram A3 for additional details and section labeled A3 Diagram Approve 
Retirement (A3) for additional details. 

See figure labeled MARS 0V-5b AO Retire Application Diagram below to depict MARS AO decomposition diagram functions. 
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NODE: 


AO 


TITLE: 


Retire Application 


NO.: 


1 


MARS 05-2 


Figure 12 MARS OV-5b AO Retire Application Diagram 
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A1 Diagram Verify Metadata (Al): activity is composed of three activities that describe how the metadata is verified by the 
MSFC RNO, MSFC Application Portfolio Manager, and the MSFC Stakeholder. The decomposed activities within Al Verify 
Metadata (Al) maintain the same set of controls that were previously defined within the parent function. The Al Verify 
Metadata (Al) function is decomposed into a child diagram. The inputs, outputs, and mechanisms are described below with the 
decomposed functions. 

• All Diagram Verify Metadata RNO (Al.l) - The first step in the process is Verify Metadata - RNO (Al.l). The details of the function 
have been decomposed into a child diagram labeled All. Verify Metadata - RNO (Al.l) details the steps that the MSFC RNO 
perform in order to verify the metadata. Input into the function is As-ls Portfolio and the As-ls Architecture. The output from the 
function is RNO Verified Metadata - 02. The mechanisms for the function are the MSFC EA (M5) and MSFC RNO (M6) roles. The 
MSFC Email System (M8) is also a mechanism used by the roles to transfer the metadata. See child diagram All for additional details 
( All Diagram Verify Metadata RNO (Al.l)) . 

• A12 Diagram Verify Metadata - Application Portfolio Manager (A1.2) - is the second function in the process. The details of the 
function are decomposed into a child diagram labeled A12 Verify Metadata - Application Portfolio Manager (A1.2). The Verify 
Metadata - Application Portfolio Manager (A1.2) details the steps that the MSFC Application Portfolio Manager perform in order to 
verify the metadata. The input for the function RNO Verified Metadata - 02. The output for the function is Portfolio Manager 
Verified Metadata - 05. The mechanisms are MSFC Application Portfolio Manager (Ml), MSFC Stakeholder (M4), and MSFC EA roles 
(M5). The MSFC Email System (M8) is also a mechanism used by the roles to transfer the metadata. See child diagram A12 for 
additional details (A12 Diagram Verify Metadata - Application Portfolio Manager (A1.2) ). 

• A1.3 Submit Application Portfolio Manager Metadata (IE7) - is the third function in the process. This function is not decomposed 
within the MARS architecture, so it does not contain a child diagram. This function depicts the activity where the stakeholder 
verified metadata is forwarded to the next step in the process, Analyze Data (A2). The input to the function is the RNO Verified 
Metadata - 02. The output from this function is Verified Application Metadata - 03. The mechanisms are the MSFC EA (M5), MSFC 
RNO (M6), MSFC Stakeholder (M4), and the MSFC Application Portfolio Manager (Ml). The MSFC Email System (M8) is also a 
mechanism used by the roles to transfer the metadata. 

See figure labeled MARS 0V-5b Al Verify Metadata (Al) below to depict the functions that compose the Al function, Verify 
Metadata (Al). 
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Figure 13 MARS OV-5b A1 Verify Metadata (Al) 
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All Diagram Verify Metadata RNO (Al.l): Diagram All that depicts the decomposed functions of A1 Verify Metadata - RNO 
(Al.l) contains five functions. None of the functions on the diagram have been decomposed into child diagrams. All of the 
functions have the controls from the parent AO diagram. The inputs, outputs, and mechanisms are described below with the 
decomposed functions. 

• Submit RNO Verify (Al.1.1) - The first function is Submit RNO Verify (Al.1.1). This is the function where the MSFC RNO metadata, 
gathered from the APMS system that is depicted in the MARS SV-1 System Interface Description, and the information is move to the 
step one of the A-0 Retire Application function, RNO Verify Initial Metadata (Al.l. 2). This function is where the metadata is received 
for later review. The input for this function is As-ls Portfolio and the as-IS Architecture. The output for the function is RNO Verified 
Metadata - 02 or the RNO Metadata Spreadsheet. The spreadsheet is the output if there are any changes that need to occur to the 
metadata. The mechanisms used in this function are the MSFC EA (M5) and the MSFC Email System (M8). 

• RNO Verify Initial Metadata (Al.1.2) - The second function is RNO Verify Initial Metadata (Al.l. 2). This is the function where the 
metadata that the MSFC RNO received is actually reviewed for the correct content. The input to the function is the RNO Metadata 
Spreadsheet. This function has two outputs. One output, 02 occurs once the metadata is correct. If the metadata is not correct, 
then the RNO metadata moves as output to the function RNO Update Initial Metadata (Al.l. 3). The mechanisms used in this 
function are the MSFC RNO (M6) and the MSFC Email System (M8). 

• RNO Update Initial Metadata (Al.1.3) - The third function is RNO Update Initial Metadata (A. 1.1.3). This is the function where the 
MFSC RNO updates the metadata if the received metadata was incorrect. If the MSFC RNO is able to update the metadata based 
upon the information received, then the metadata is moved as output RNO Issues to the next function Submit RNO Questions 
(Al.l. 4). If the MSFC RNO is able to update the metadata based upon the existing metadata or expert knowledge, then the 
metadata is move out as RNO Verified Metadata - 02 to step four. The input for the function is RNO Metadata. The mechanisms 
used in this function are MSFC RNO (M6) and the MSFC Email System (M8). 

• Submit RNO Questions (Al.1.4) - The forth function is Submit RNO Questions (A. 1.1.4). This is the function where the MSFC RNO 
compiles and submits a list of questions to the MSFC EA based upon the incorrect metadata received. The MARS OV-3 Operational 
Resource Flow Matrix details the information exchange occurs between Submit RNO Questions (Al.1.4), Answer RNO Questions 
(Al.l. 5) performed by the MSFC EA and the output loop where the RNO Answered Questions are input to the RNO Verify Initial 
Metadata (Al.1.2) function. If the questions are not answered in the next function, Answer RNO Questions (1.1. 1.5), then the loop 
restarts at RNO Verify Initial Metadata (Al.1.2). Once the questions are properly answered then the loop stops by the metadata 
moving out over RNO Verified Metadata - 02 to the next step described in A12 Verify Metadata Application Portfolio Manager 
(A1.2) function. The input for the function is RNO Issues. The mechanisms used in this function are MSFC RNO (M6) and the MSFC 
Email System (M8). 
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• Answer RNO Questions (Al.1.5) -The last function on the diagram is where the MFSC RNO Questions are answered by the MSFC EA. 
The input for the function is RNO Questions. The mechanisms used in this function are MSFC EA (M5), MSFC RNO (M6), and the 
MSFC Email System (M8). The output from this function loops back to RNO Verify Initial Metadata (Al.1.2) until the MSFC RNO 
questions are properly answered. 

See figure labeled MARS OV-5b All Verify Metadata - RNO (Al.l) below to depict the functions that compose the All function, 

Verify Metadata - RNO (Al.l). 
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Dated: 12 June 2010 



MARS 05-4 

Figure 14 MARS OV-5b All Verify Metadata - RNO (Al.l) 
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A12 Diagram Verify Metadata - Application Portfolio Manager (A1.2): The diagram A12 depicts the decomposed functions of 
A1 Verify Metadata Application Portfolio Manager (A1.2). This function contains three sub-functions. None of the functions on 
the diagram have been decomposed into child diagrams. All of the functions on the diagram have the controls from the parent 
A-0 Context diagram. The inputs, outputs, and mechanisms are described below with the decomposed functions. 

• Stakeholder Application Metadata Verification (Al. 2.1) - The first function is Stakeholder Application Metadata Verification 
(Al.2.1). This is the function where the Stakeholder Verified Metadata is returned and verified by the MSFC Application Portfolio 
Manager for completeness. The input for the function is RNO Verified Metadata - 02. The output from the function portfolio 
Manager Verified Metadata - 05. The mechanisms used in this function are the MSFC Application Portfolio Manager (Ml), MSFC 
Stakeholder (M4), and MSFC EA (M5) roles. The MSFC Email System (M8) is used by the roles to transfer the metadata. 

• Stakeholder Application Metadata Update (Al.2.2) - The second function is Stakeholder Application Metadata Update (Al.2.2). 
This is the function where the Stakeholder Verified Metadata that has been updated is returned, changes reviewed and then the 
data verified by the MSFC Application Portfolio Manager for completeness. The input for the function is the RNO Verified Metadata 
- 02. The output from the function portfolio Manager Verified Metadata - 05. The mechanisms used in this function are the MSFC 
Application Portfolio Manager (Ml), MSFC Stakeholder (M4), and MSFC EA (M5) roles. The MSFC Email System (M8) is used by the 
roles to transfer the metadata. 

• Return Application Assessment (Al.2.3) - The third and last function is Return Application Assessment (Al.2.3). This is the function 
where the MSFC Application Portfolio Manager creates the final metadata package and confirms delivery of the metadata to the 
MSFC EA. The mechanisms used in this function are the MSFC Application Portfolio Manager (Ml) and MSFC EA (M5) roles. The 
MSFC Email System (M8) is also a mechanism used by the roles to transfer the metadata. 

See figure labeled MARS 0V-5b A12 Verify Metadata - Application Portfolio Manager (A1.2) below to depict the functions that 
compose the A12 function, Verify Metadata - Application Portfolio Manager (A1.2). 
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viewpoints. 


NODE: 


A12 TITLE: 


Verify Metadata - Application Portfolio Manager (A1.2) 


NO.: 


MARS 05-5 


Figure 15 MARS OV-5b A12 Verify Metadata - Application Portfolio Manager (A1.2) 
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A2 Diagram A2 Analyze Data (A2j: activity is composed of four functions that describe how the metadata is analyzed by the 
MSFC EA to produce the list of application that are sent to the MSFC MEAAC to produce a recommendation. The decomposed 
functions within A2 Analyze Data (A2) maintain the same set of controls that were previously defined within the parent function, 

A-0. The A2 Analyze Data (A2) function is decomposed into a child diagram. The inputs, outputs, and mechanisms are described 
below with the decomposed functions. None of the functions are decomposed into child diagrams. 

• Conduct Assessment (A2.1) - The first step in the function is Conduct Assessment - RNO (A2.1). The function details the steps that 
the MSFC EA performs in order to verify the returned metadata and compare the metadata with the original metadata. This step 
also includes summary assessment of the returned metadata. The input for the function is Verified Application Metadata - 03. The 
output from this function is the Complied Data that has been summarized. The mechanisms for this function are MSFC EA (M5) role 
and the MSFC Email System (M8). 

• Conduct and Submit Initial Analysis (A2.2) - The second step in the function is Conduct and Submit Initial Assessment - RNO (A2.2). 
The function details the steps that the MSFC EA performs to actually perform the application analysis of applying new MARS Score 
Application Capability to the metadata in order to generate the list of potential retirement applications. The MARS Score Application 
capability combines the business score, retirement score, and technical score that is defined within the MARS CV-2 Capability 
Taxonomy to create the Application Portfolio Analysis depicted within the MARS OV-1 High-Level Operational Concept Graphic. T he 
input to the function is Complied Data. After creating the initial analysis the MFSC EA, the output from this function is the 
Recommended Retirement Applications - 04. The mechanisms for this function are MSFC EA (M5) role and the MSFC Email System 
(M8). 

• Review Initial Analysis (A2.3) - The third step receives the input from Conduct and Submit Initial Analysis (A2.2) where the MSFC EA 
provides the input into this function, Initial Assessment. The input for the function is Initial Assessment. This function is where the 
MSFC Application Portfolio Manager confirms that the targeted list of application are valid before submitting output from this 
function, the Updated Initial Assessment. The mechanisms for this function are the MSFC Application Portfolio Manager (Ml) and 
the MFSC EA (M5) roles, and the MFSC Email System (M8) that provides the system interaction to exchange the analysis. 

• Conduct and Submit Final Analysis (A2.4) - The last step is the MSFC EA performs any final updates to the analysis and then submits 
the Recommended Retirement Applications - 04. The input for the function is Updated Initial Assessment. The output from the 
function is Recommended Retirement Applications - 04. The mechanisms for this function are the MSFC EA (M5) role and the MSFC 
Email System (M8) which provides the system interface to submit the recommended list of applications. 

See figure labeled MARS 0V-5b A2 Analyze Data (A2) below to depict the functions that compose the A2 function, Analyze Data 
(A2). 
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Tailoring: The OV-5a Operational Activity Decomposition Tree node identifiers have been included for 
referential integrity across the viewpoints. 


NODE: 


A2 
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Analyze Data (A2) 


NO.: 
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Figure 16 MARS OV-5b A2 Analyze Data (A2) 


MARS Architecture Practicum Report, rev-3 


12 June 2010 


Page 64 


A3 Diagram Approve Retirement (A3): activity is composed of three functions that describe how the recommended retirement 
application list provided as output 04 by Analyze Data (A2) is reviewed by the MSFC MEAAC and the MSFC CIO for approval. The 
approval is then submitted to the MSFC RNO for implementation. The decomposed activities within A3 Approve Retirement (A3) 
maintain the same set of controls that were previously defined within the parent function, A-0. The A3 Approve Retirement (A3) 
function is decomposed into a child diagram. The inputs, outputs, and mechanisms are described below with the decomposed 
functions. None of the functions are decomposed into child diagrams. 

• Submit Retirement Recommendation (A3.1) - The first step in the function is Submit Retirement Recommendation (A3.1). The input 
to the function is the Recommended Retirement Applications - 04 received from the MSFC EA in function Conduct and Submit Final 
Analysis (A2.4). The function details the steps that the MSFC MEAAC performs in order to approve the submitted list of 
Recommended Retirement Applications - 04 that were received as input. The output from the function is the MEAAC approved list 
of MSFC MEAAC Recommended Retirement Applications. The mechanisms for this function are MSFC MEAAC (M3) role and the 
MSFC Email System (M8) that provides the system interface to exchange the recommendation. 

• Approve Recommendation (A3. 2) - The second step in the function is Approve Recommendation (A3. 2). The function details the 
steps that the MSFC CIO performs in order to approve the submitted list of MEAAC Recommended Retirement Applications - 04 
that were received as input. The output from the function is the MEAAC approved list of MSFC MEAAC Recommended Retirement 
Applications. The mechanisms for this function are MSFC MEAAC (M3) role and the MSFC Email System (M8) that provides the 
system interface to exchange the recommendation. 

• Initiate Retirement (A3. 3) - The third and final step in the function depicts the functions necessary for the Approved Retirement 
Applications - 04 that is communicated to the MSFC MEAAC and finally to the MSFC RNO for implementation. The input for the 
function is Approved Retirement List. The output for the function is the Realigned Portfolio - 01. The mechanisms for the function 
are the MSFC MEAAC (M3), MSFC RNO roles (M6), and the APMS (M7) and MSFC Email system (M8). Both systems provide the 
automation behind the communication and documentation of the list of applications to be retired. 

See figure labeled MARS 0V-5b A3 Approve Retirement (A3) below to depict the functions that compose the A3 function, 

Approve Retirement (A3). 
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PURPOSE: Depicts executive decision making activity that finalizes the retirement recommendation to realign 
the portfolio performed by the MSFC Responsible NASA Officer (RNO) performer. 

VIEWPOINT: MSFC MEAAC 


Tailoring: The OV-5a Operational Activity Decomposition Tree node identifiers have been included for 
referential integrity across the viewpoints. 


Approve Retirement (A3) 


MARS 05-7 


Figure 17 MARS OV-5b A3 Approve Retirement (A3) 
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14.2.4 View Integration 

The MARS 0V-5b was integrated with the MARS 0V-5a by appending the MARS 0V-5a node identifier to the description of the 
function. This integration provides the MARS Architecture (and architects and reviewers) the ability to perform a quick reference 
between the two "companion" views. 

The MARS OV-5b was also integrated with the MARS OV-2 by using the operational performers from the OV-2 as the 
mechanisms on the OV-5b. The function inputs and outputs are depicted on the MARS OV-3 as the information exchanges. 

The MARS OV-5b was also integrated with the MARS SV-1 by using the resources on the SV-1 as mechanisms in the MARS OV-5b. 

The MARS OV-5b was also integrated with the MARS StdV-1 Standards Profile. The technology that is used by the mechanism is 
defined within the MARS StdV-1 view. 

14.2.5 Stakeholder Questions Addressed 

• SQ-03 How can MSFC determine the extent of underused, unused, low business value, and/or low technology value 
applications in its application portfolio? 

• SQ-04 How can MSFC determine the extent of overlapping functionality within its application portfolio? 

• SQ-05 How can MSFC determine the cost to maintain an application in its application portfolio versus what it costs to retire 

or decommission it? 

• SQ-06 How can MSFC determine the extent of applications in its application portfolio that are still active past their target 
retirement dates? 
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15 OV-2 Operational Resource Flow Description View 

15.1 DoDAF-Described OV-2 


15.1.1 Description 

The OV-2 Operational Resource Flow Description view emphasizes nodes (or node types) and the information exchanges 
between them within the context of the operational capability depicted in the OV-1. An operational node is a node that 
performs a role or mission. The OV-2 depicts the operational players (performers or organizations) with needlines between 
those operational nodes that represent a need to exchange information or resources. 

The nodes can represent operational nodes within the architecture description or the external environment. Nodes within the 
architecture description are operational nodes that send information or receive information (or resources) from the architecture 
nodes. External operational nodes are operational nodes that send information to or receive information (or resources) from the 
architecture's nodes but are outside the scope of the architecture; and do not perform architecture activities. Nodes within a 
DoDAF view present a logical concept that represents activities, systems, organizations, persons, facilities, locations, materials, 
and installations that produce, consume, or processes data. 

15.1.2 View Guidance and Characteristics 

The OV-2 logical pattern need not correspond to specific organizations, systems, or locations. This allows resource flows to be 
established without prescribing the way the resource flows are handled and without prescribing solutions. The OV-2 is intended 
to be logical. It describes who or what; not how. The OV-2 provides a focus for the operational requirements that may reflect 
any capability requirements that have been articulated but within the range of operational settings that are being used for 
operational architecture. 

The OV-2 describes to non-technical stakeholders how resources flow (or do not flow). The aim of the view is to record the 
operational characteristics for the community of anticipated users relevant to the architecture description and their 
collaboration needs, as expressed in needlines and resource flows. 

Figure Example Operational Resource Flow Description below shows an example OV-2. The view shows three operational nodes 
(Node A, Node B, and Node C) that indicate the Information being exchanged between the architecture operational nodes (Type 
X, Y, and Z). The example also shows Node B exchanging information Type W with an external destination that is outside of the 
architecture description. 
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Needline Z,*' 
Information Type W 


External 
Destination L 



Information Type Z 


External 
Source M 


Figure 18 Example Operational Resource Flow Description 

15.1.3 Purpose 

The OV-2 primary purpose is to define capability requirements within an operational context. The OV-2 may also be used to 
express a capability boundary. The OV-2 may also be used to express a capability boundary. 

The OV-2 intended uses include: 

• Depict needs for information exchanges that support resource flows 

• Depict key operational players (performers) and their interactions within the resource exchanges 

• Indicate need for interfaces to support resource flows shown within the information exchange 

• Summarize resource flows using needlines 
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15.1.4 Audience 

The OV-2 has two audiences; one for the information flow and the other for resource flow. 

The information flow audience includes: 

• Systems interfaces developers 

• Communications infrastructure personnel 

• Service infrastructure personnel 

The resource flow audience includes logistics personnel. 

15.2 MARS Architecture OV-2 

15.2.1 Tailoring Applied 

The authors tailored the MARS OV-2 to include the operational activities and their node identifiers, which were decomposed 
within the MARS OV-5a ( OV-5a Operational Activity Decomposition Tree View ) and modeled in the MARS OV-5b ( OV-5b 
Operational Activity Model View ). Each activity shown in the OV-2 has the needline identified that is integrated into the MARS 
OV-3 described in section labeled OV-3 Operational Resource Flow Matrix View. 

15.2.2 Viewpoint 

The viewpoint of the MARS OV-2 is the MEAAC. 

15.2.3 View Discussion 

The MARS OV-2 depicts the operational key players (performers) within the MARS Architecture and the necessary information 
exchanged between each operational player (performer). 
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Table 4 MARS OV-2 Operational Node Requirements 

Operational Role 
(Performer) 

Performer Operational Activity Requirement 

MARS OV-5A Nodes 

MSFCCIO 

Approve the retirement recommendation and exchanges the retirement approval with 
the MSFC RNO 

A3. 2 Approve Retirement 
(IE14) 

MSFC MEAAC 

Create the retirement recommendation for MSFC CIO approval and exchanges the 
recommendation with the MSFC CIO. The MSFC MEEAC receive analysis 
recommendation from the MSFC EA. 

A3.1 Submit Retirement 
Recommendation (IE12) 

MSFC Responsible 
NASA Officer (RNO) 

Confirm the application metadata and communicates information exchange with the 
MSFC EA. 

Al.l Verify Metadata -RNO 

MSFC Application 
Portfolio Managers 

Confirm the application metadata and coordinate with the MSFC Stakeholder to 
ensure that the metadata is correct. Review MSFC EA preliminary analysis for 
completeness before analysis submitted to the MSFC MEAAC. 

Al.2.3 Return Application 
Metadata and 
A2.3 Review Initial Analysis 
(IE10) 

MSFC Stakeholder 

Review and verify the application metadata provided by an information exchange with 
the MFSC Application Portfolio Manager. Update metadata is necessary before 
verification. 

Al.2.1 Stakeholder Application 
Metadata Verification (IE6) 
and 

Al.2.2 Stakeholder Application 
Metadata Update (IE6) 

MSFC EA 

Perform analysis necessary to provide an analysis summary to the MSFC MEAAC. 
MSFC EA exchanges the metadata with the MSFC RNO, MSFC Portfolio Manager, and 
then exchanges the completed assessment to the MSFC MEAAC. 

A2.1 Conduct Assessment 
(IE5), 

A2.3 Conduct and Submit 
Initial Analysis (IE8), and 
A2.4 Conduct and Submit Final 
Analysis (IE11) 
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15.2.4 View Integration 

The MARS OV-2 was integrated into the MARS OV-3 as described in Tailoring Applied above. See section labeled OV-3 
Operational Resource Flow Matrix View for additional information. 

The MARS Architecture also shows the integration between the MARS OV-5a by adding the MARS OV-5a operational node 
identifiers to the node activities shown on the OV-2. See sections labeled OV-5a Operational Activity Decomposition Tree View 
and OV-5b Operational Activity Model View. 

The needlines established in the MARS OV-2 are realized by system resources and their interactions depicted in the MARS SV-1. 
See section labeled SV-1 Systems Interface Description View f or additional details regarding the MARS SV-1 view. 

15.2.5 Stakeholder Questions Addressed 

• SQ-03 How can MSFC determine the extent of underused, unused, low business value, and/or low technology value 
applications in its application portfolio? 

• SQ-04 How can MSFC determine the extent of overlapping functionality within its application portfolio? 

• SQ-05 How can MSFC determine the cost to maintain an application in its application portfolio versus what it costs to retire 
or decommission it? 

• SQ-06 How can MSFC determine the extent of applications in its application portfolio that are still active past their target 
retirement dates? 
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MARS Architecture OV-2 Operational Resource Flow Description 


Dated: 12 June 10 


MARS Architecture Boundary 


jMSFC CIO Activities: 

j* IE1 3: A3. 2 Approve 

! Recommendation 



JMSFC RNO Activities: 

j. IE2: A1.1.2 RNO Verify Initial Metadata 
•• IE2: A1.1.3 RNO Update Initial Metadata 
j* IE2: A1.1 .4 Submit RNO Questions 
*• IE4: RNO Verified Metadata 


JMSFC EA Activities: 

IE1: A1.1.1 Submit RNO Verify 
IE3: A1 .1 .5 Answer RNO Questions 
IE5:A2.1 Conduct Assessment 
IE9: A2.2 Conduct and Submit Initial Analysis 
IE1 1 : A2.4 Conduct and Submit Final Analysis 


JVISFC Application Portfolio Manager Activities: 

•• IE8: A1 .2.3 Return Application Metadata 
U IE7: A1 .3 Submit Application Portfolio Manager Metadata 
J* IE10: A2.3 Review Initial Analysis 



JVISFC Stakeholder Activities: 

j* IE6: A1.2.1 Stakeholder Application Metadata 
j Verification 
U IE6: A1 .2.2 Stakeholder Application Metadata Update j 


MARS 06 


Figure 19 MARS OV-2 Operational Resource Flow Description 
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16 OV-3 Operational Resource Flow Matrix View 

16.1 DoDAF-Described OV-3 

16.1.1 Description 

The OV-3 Operational Resource Flow Matrix addresses operational resource flows exchanged between operational activities and 
locations. The OV-3 identifies the resource transfers that are necessary to support operations to achieve a specific operational 
activity. The OV-3 is constructed from the information contained in the OV-2. 

The OV-3 emphasizes the logical and operational characteristics of the resource flows being exchanged, with focus on the 
resource flows crossing the capability boundary. The OV-3 is not intended to be an exhaustive listing of all the details contained 
in every resource flow of every operational activity and location associated with the architecture description. The OV-3 is 
intended to capture the most important aspects of selected resource flows and there is not always a one-to-one mapping of 
OV-3 resource flows to OV-2 operational resource flow description needlines. 

The OV-3 information can be presented in tabular form and the DoDAF V2.0 Volume II does not prescribe column headings for 
an OV-3 matrix. Most OV-3 matrixes show the needline identifier, information provider, and consumer of the information 
exchange as a minimum list. The matrix details information exchanges and identifies who exchanges what information, with 
whom, why the information is necessary, and how the information exchange must occur. The matrix should also contain the key 
attributes of the associated resources and the triggering event. 

16.1.2 Purpose 

The OV-3 purpose is to define interoperability requirements. The OV-3 also ties together role, activity, and resource flow 
between the key architecture description operational performers that are fulfilling the architecture description mission. The 
OV-3 can also help define the agreements that can be created between different organizations about timeframes in which the 
exchanges need to occur to fulfill the mission objective or capability. 

16.1.3 Audience 

The OV-3 audience includes: 

• Operational analysts 

• Communications analysts 

• Supply logisticians 
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16.2 MARS Architecture OV-3 

16.2.1 Tailoring Applied 

The authors did not tailor the MARS OV-3 since DoDAF V2.0 does not prescribe the column headings in an OV-3. 

16.2.2 Viewpoint 

The viewpoint of the MARS OV-3 is the MEAAC. 

16.2.3 View Discussion 

The authors indicated in the MARS OV-3 the needline identifier, the information element (what is being exchanged), the 
provider (who provides the information exchange element), the consumer (who is receiving the information exchange element), 
the transition information (what is being exchanged, how the information element is being exchanged, when the exchange 
occurs or the triggering event), and the performance attributes (why the information is being exchange and what the exchange 
is measured against). 

The authors appended the MARS OV-5a node identifiers to the activities and ensured that the MARS OV-4 roles were listed as 
the provider and consumer of the information exchange. 

The MARS OV-3 shows the required interaction with the APMS shown in the section labeled SV-1 Systems Interface Description 
View to perform the information exchanges. After the metadata is retrieved, the MARS OV-3 shows verifying the metadata with 
the MSFC RNO (Needlines IE1-IE4), to verifying the metadata with the Application Portfolio Manager (Needlines IE6-IE8), to 
conducting and submitting the analysis to the MEAAC (Needlines IE-9 - IE12). Finally, the OV-3 shows the MSFC CIO approval (IE- 
13) and the process of initiating the retirement with the MSFC RNO (Needline IE14). 

Each needline describes how the operational performer described in the MARS OV-2 will exchange the information element and 
the triggering event that causes the exchange. See section labeled OV-2 Operational Resource Flow Description View for 
additional details on the MARS OV-2 view. 

16.2.4 View Integration 

The authors used MARS OV-5a decomposed activities to define the activities that required the information exchanges shown on 
the MARS OV-3. The authors also used the defined inputs, outputs, mechanisms, and controls within the MARS OV-5b to help 
define the types of information exchange between the activities. 

For additional information on the MARS OV5a, see the section labeled OV-5a Operational Activity Decomposition Tree View and 
section labeled OV-5b Operational Activity Model View for the OV5b view. 
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16.2.5 Stakeholder Questions Addressed 

• SQ-03 How can MSFC determine the extent of underused, unused, low business value, and/or low technology value 
applications in its application portfolio? 

• SQ-04 How can MSFC determine the extent of overlapping functionality within its application portfolio? 

• SQ-05 How can MSFC determine the cost to maintain an application in its application portfolio versus what it costs to retire 
or decommission it? 

• SQ-06 How can MSFC determine the extent of applications in its application portfolio that are still active past their target 
retirement dates? 
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Figure 20 MARS OV-3 Operational Resource Flow Matrix 


MARS Architecture OV-3 Operational Resource Flow Matrix 
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spreadsheet 

received 

within 40 
hours of 
spreadsheet 
receipt 

once (5) 

spreadsheet 

receipt 

IE2 

Al.1.3 RNO Update Initial 
Metadata 

MSFC 

Responsible 
NASA Official 
(RNO) 

MSFC RNO 

MSFC 

Enterprise 

Architect 

MSFC EA 

spreadsheet 

email 

spreadsheet 

received 

within 40 
hours of 
spreadsheet 
receipt 

once @ 

spreadsheet 

receipt 

IE2 

Al.1.4 Submit RNO 
Questions 

MSFC 

Responsible 
NASA Official 
(RNO) 

MSFC RNO 

MSFC 

Enterprise 

Architect 

MSFC EA 

verbal 

meeting 

spreadsheet 

received 

during 

meeting 

many until 
questions 
answered 

IE3 

Al.1.5 Answer RNO 
Questions 

MSFC Enterprise 
Architect 

MSFC EA 

MSFC 

Responsible 
NASA Official 
(RNO) 

MSFC RNO 

verbal 

meeting 

spreadsheet 

received 

during 

meeting 

many until 
questions 
answered ; 

IE4 

RNO Verified Metadata 

MSFC 

Responsible 
NASA Official 
(RNO) 

MSFC RNO 

MSFC 

Enterprise 

Architect 

MSFC EA 

spreadsheet 

email 

spreadsheet 

received 

within 40 
hours of 
spreadsheet 
receipt 

once @ ! 

spreadsheet 
receipt ( 
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Information 
Element (What) 

Provider (Who) 

Consumer (Who) 

Transition Information 
(What) (How) (When) 

Performance 
Attributes (Why) 

Needline 

Identifier 

Description (Activity) 

Sender Entity 
(role) 

Sender Node 
Activity 

Receiving 
Entity (role) 
(Who) 

Receiving 

Node 

Activity 

Information 

Element 

Type 

(Verbal, 

email) 

Mechanism 

Triggering 

Event 

Timeliness 

Frequency 

IE5 

A2.1 Conduct Assessment 

MSFC 

Enterprise 

Architect 

MSFC EA 

MSFC 

Application 

Portfolio 

Manager 

MSFC 

Application 

Portfolio 

Manager 

spreadsheet 

email 

spreadsheet 

received 

within 40 
hours of 
spreadsheet 
receipt 

once (5) 

spreadsheet 

receipt 

IE6 

Al.2.1 Stakeholder 
Application Metadata 
Verification 

MSFC 

Application 

Portfolio 

Manager 

MSFC 

Application 

Portfolio 

Manager 

MSFC 

Stakeholder 

MSFC 

Stakeholder 

spreadsheet 

email 

spreadsheet 

received 

within 40 
hours of 
spreadsheet 
receipt 

once @ 

spreadsheet 

receipt 

IE6 

Al.2.2 Stakeholder 
Application Metadata 
Update 

MSFC 

Application 

Portfolio 

Manager 

MSFC 

Application 

Portfolio 

Manager 

MSFC 

Stakeholder 

MSFC 

Stakeholder 

spreadsheet 

email 

spreadsheet 

received 

within 40 
hours of 
spreadsheet 
receipt 

once @ 

spreadsheet 

receipt 

IE7 

A1.3 Submit Application 
Portfolio Manager 
Metadata 

MSFC 

Stakeholder 

MSFC 

Stakeholder 

MSFC 

Application 

Portfolio 

Manager 

MSFC 

Application 

Portfolio 

Manager 

spreadsheet 

email 

spreadsheet 

received 

within 40 
hours of 
spreadsheet 
receipt 

once @ | 

spreadsheet 

receipt 

IE8 

Al.2.3 Return Application 
Metadata 

MSFC 

Application 

Portfolio 

Manager 

MSFC 

Application 

Portfolio 

Manager 

MSFC 

Enterprise 

Architect 

MSFC EA 

spreadsheet 

email 

spreadsheet 

received 

within 8 
hours of 
spreadsheet 
receipt 

once @ [ 

spreadsheet 

receipt 

IE9 

A2.2 Conduct and Submit 
Initial Analysis 

MSFC 

Enterprise 

Architect 

MSFC EA 

MSFC 

Application 

Portfolio 

Manager 

MSFC 

Application 

Portfolio 

Manager 

spreadsheet 

email 

spreadsheet 

received 

within 40 
hours of 
spreadsheet 
receipt 

once @ 

spreadsheet 

receipt 

1 E 10 

A2.3 Review Initial 
Analysis 

MSFC 

Application 

Portfolio 

Manager 

MSFC 

Application 

Portfolio 

Manager 

MSFC 

Enterprise 

Architect 

MSFC EA 

spreadsheet 

email 

spreadsheet 

received 

within 40 
hours of 
spreadsheet 
receipt 

once @ 

spreadsheet 

receipt 
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Information 

Element 

(What) 

Provider (Who) 

Consumer (Who) 

Transitic 

>n Information (What) 
How) (When) 

Performance 
Attributes (Why) 

Needline 

Identifier 

Description 

(Activity) 

Sender 
Entity (role) 

Sender 

Node 

Activity 

Receiving 
Entity (role) 
(Who) 

Receiving 

Node 

Activity 

Information 

Element 

Type 

(Verbal, 

email) 

Mechanism 

Triggering 

Event 

Timeliness 

Frequency 

IE11 

A2.4 Conduct and 
Submit Final Analysis 

MSFC 

Enterprise 

Architect 

MSFC EA 

MSFC 

Enterprise 

Architecture 

Advisory 

Committee 

(MEAAC) 

MSFC 

MEAAC 

Report 

email 

Completed 

analysis 

within 16 
hours of 
final 
meeting 

once @ 

completed 

analysis 

1 E 12 

A3.1 Submit 
Retirement 
Recommendation 

MSFC 

Enterprise 

Architecture 

Advisory 

Committee 

(MEAAC) 

MSFC 

MEAAC 

MSFC Chief 
Information 
Officer 

MSFC CIO 

Report 

meeting 

Completed 

Recommendation 

within 16 
hours of 
analysis 
receipt 

once @ 

completed 

recommendation 

IE13 

A3. 2 Approve 
Recommendation 

MSFC Chief 
Information 
Officer 

MSFC CIO 

MSFC 

Enterprise 

Architecture 

Advisory 

Committee 

(MEAAC) 

MSFC 

MEAAC 

Report 

meeting 

Approval 

Within 40 
hours of 
report 
receipt 

once @ 

completed 

decision 

IE14 

A3. 3 Initiate 
Retirement 

MSFC 

Enterprise 

Architecture 

Advisory 

Committee 

(MEAAC) 

MSFC 

MEAAC 

MSFC 

Application 

Portfolio 

Management 

System 

(APMS) 

MSFC RNO 

Workflow 

process 

CIO Approval 

Within 40 
hours of 
approval 

once @ 

completed 

decision 










Dated: 

12-Jun-10 
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17 SV-1 Systems Interface Description View 

17.1 DoDAF-Described SV-1 

17.1.1 Description 

The SV-1 System Interface Description view depicts system locations required to support organizations/human roles represented 
by operational performers on the OV-2. The SV-1 also identifies the interfaces between systems to other systems or between 
systems and location combinations. 

The SV-1 links the operational and system architecture views by depicting how resources are structured and interact to realize 
the logical architecture specified in an OV-2. The SV-1 represents the realization of a requirement specified in an OV-2 
operational performer. 

A system resource flow is a simplified representation of a pathway or network pattern, usually depicted graphically as a 
connector (i.e., a line with possible amplifying information such as network protocol). The SV-1 depicts all system resource flows 
between systems that are of interest within the architecture description. 

The benefit of an SV-1 is its ability to show the architecture operational performers and how they interact with the systems 
shown on the SV-1. The structural and behavioral viewpoints in the OVs and SVs allow architects and stakeholders to quickly 
ascertain which functions are carried out by operational performers and which by systems for each alternative specification and 
to carry out trade analysis. 

17.1.2 Purpose 

The SV-1 purpose is to show resource structure, i.e., identify the primary sub-systems, operational performers and activities 
(functions), and their interactions. The SV-1 contributes to an understanding of the structural characteristics of the capability. 

The SV-1 intended use includes: 

• Define system concepts 

• Define system options 

• Capture system resource flow requirements 

• Plan capability integration 

• Manage system integration 

• Plan operation (capability and performer definition) 

• Relate system locations and systems-to-operational performers 
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• Identify cross-organizational interfaces (key interfaces) 

• Support system acquisition 

• Determine needs for system interoperability 

• Provide a high-level view of all interfaces required by a architecture scope 

17.1.3 Audience 

The SV-1 audience includes: 

• System architects 

• Major system requirements personnel 

• System analysts 

17.2 MARS Architecture SV-1 

17.2.1 Tailoring Applied 

The authors tailored the MARS SV-1 by annotating the system interface with the network protocols that transverse the network 
and also identifying the first level of operational activities specified with the MARS OV-5a. The authors also depicted the 
operational performers on the graphic that were defined in the MARS OV-2. 

17.2.2 Viewpoint 

The viewpoint of the MARS SV-1 is the MEAAC. 

17.2.3 View Discussion 

The MARS SV-1 decomposes the APMS into its three systems: 

• The MSFC Portfolio Data Store (DS) Web Server that provides the web connectivity to the users of the system 

• The MSFC Portfolio DS Application Server that runs the application portfolio application software that interfaces with the 
MSFC Portfolio DS Web Server and the MSFC Portfolio DS Database Server to retrieve data 

• The MSFC Portfolio DS Database Server that host the actual database that contain the four application portfolios 

The SV-1 also depicts the key performers within the MARS Architecture: the MFSC EA, MSFC RNO (RNO), MSFC Application 
Portfolio Manager, MSFC Stakeholder, MFSC MEAAC, and the MSFC CIO. All operational performers use their laptops to connect 
via the network to the APMS. 
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17.2.4 View Integration 

The MARS SV-1 depicts the key performers within the MARS Architecture. Each system interface has been labeled with the 

MARS OV-5a top-level of decomposed activities that show what operational activity the operational performer is using the 

systems to perform. This ties together the operational activities, operational performers, and required systems in one view. 

The MARS OV-3 uses the systems specified in the SV-1 to perform the information exchanges. The technical standards required 

by the systems are specified in the MARS StdV-1. 

17.2.5 Stakeholder Questions Addressed 

• SQ-03 How can MSFC determine the extent of underused, unused, low business value, and/or low technology value 
applications in its application portfolio? 

• SQ-04 How can MSFC determine the extent of overlapping functionality within its application portfolio? 

• SQ-05 How can MSFC determine the cost to maintain an application in its application portfolio versus what it costs to retire 
or decommission it? 

• SQ-06 How can MSFC determine the extent of applications in its application portfolio that are still active past their target 
retirement dates? 
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Dated: 12 June 2010 


MARS Architecture SV-1 System Interface Description 


Application Portfolio 
Management System (APMS) 


MSFC Portfolio DS 
Application Server 



HTTP- 




MSFC Portfolio DS 
Web Server 


MSFC Portfolio DS 
Database Server 


Science and Engineering 
Application Portfolio 
Project Management 
^ atabas 5 Application Portfolio 

Business Management 
Debas e Application Portfolio 

Infrastructure Services 
Database Application Portfolio 


Request APMS 
Metadata 

-HTTP- 


o 


A 

MSFC Enterprise Architect 
(EA) 


MSFC 

Responsible NASA 
Officer (NRO) 


o 


A 

MSFC Application Portfolio 
Manager 


Laptop 


PURPOSE: Depicts systems and performers involved within the Marshall Application Realignment 
System (MARS) Portfolio Management process. 

VIEWPOINT: MSFC MEAAC 

Tailoring: Annotated the system interface with the network protocols that transverse the 
network. Identified the first level of operational activities specified with the MARS OV-5a. 
Depicted the operational performers defined within the MARS OV-2. 




o 


MSFC Stakeholder 

Jr 

^Laptop 


/ & 


GP 

MSFC Email System 



MSFC MEAAC 


MARS 08 


Figure 21 MARS SV-1 System Interface Description 
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18 OV-4 Organizational Relationships Chart View 

18.1 DoDAF-Described OV-4 

18.1.1 Description 

The OV-4 Organizational Relationship Chart view shows organizational structures and interactions. The OV-4 can be role based 
or based on the actual organization structure. 

A role-based OV-4 shows the architecture relationships between organizational resources. The key relationship is shown on the 
graphic and how the organization fits into a larger enterprise organization or parent organization. The OV-4 may also show the 
roles each organizational resource has, and the interactions between those roles, i.e., the roles represent the functional aspects 
of organizational resources. 

18.1.2 Purpose 

The purpose of an "actual" OV-4 is to show the structure of a real organization at a particular point in time. It is used to provide 
context to other parts of the architecture such as the AV-1 and the CV views. 

The purpose of a role-based OV-4 is to support: 

• Organizational analysis 

• Definition of human roles 

• Operational analysis 

• Identification of architecture stakeholders and process owners 

• Illustration of current or future organization structures 

18.1.3 Audience 

The OV-4 audience includes: 

• Architecture sponsors 

• Architecture stakeholders 

• Architecture development team 
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18.2 MARS Architecture OV-4 

18.2.1 Tailoring Applied 

The authors tailored the MARS OV-4 by choosing to depict the existing organization view of MSFC and how MSFC is part of a 
larger NASA organization. The authors also chose to show the roles involved within the MARS Architecture. 

18.2.2 Viewpoint 

The viewpoint of the MARS OV-4 is the MEAAC. 

18.2.3 View Discussion 

The MARS OV-4 shows the MSFC organization and what organizations are involved in the MARS Architecture. The table below 
highlights the organization, the role, and a brief description of the duties within the MARS Architecture. The table below 
contains the MARS OV-2 view node identifiers within the parentheses in the description field to relate the description to the 
information exchanges performed by the roles and what part of the MSFC Organization performs the role. 


Department (MARS OV-4) 

Role (MARS OV-2) 

Description (MARS OV-5a) 

Office of the Chief Information 
Officer (CIO) 

MSFC CIO 

Approves the recommendation to retire selected low business and technology value 
applications. (A3. 2) 

CIO - Planning, Policy & 
Integration Office 

MSFC MEAAC 
MSFC EA 

MSFC MEAAC - submits the retirement recommendation (A3.1) and initiates the 
approved retirement recommendation (A3. 3) 

CIO - IT Security Office 

MSFC RNO 

Updates the metadata (Al.1.3) or submit's questions for clarification (Al.1.4) before 
verifying the metadata (Al.1.2). 

CIO - Application, Web, and 
Multimedia Services Office 

MSFC RNO 

Updates the metadata (Al.1.3) or submit's questions for clarification (Al.1.4) before 
verifying the metadata (Al.1.2). 

CIO - Network, Telecom, and 
Desktops Services Office 

MSFC RNO 

Updates the metadata (Al.1.3) or submit's questions for clarification (Al.1.4) before 
verifying the metadata (Al.1.2). 

CIO - NEACC Business Process 
and Application Services Office 

MSFC RNO 

Updates the metadata (Al.1.3) or submit's questions for clarification (Al.1.4) before 
verifying the metadata (Al.1.2). 

CIO NEACC Application 
Development and Software 
Assurance Office 

MSFC RNO 

Updates the metadata (Al.1.3) or submit's questions for clarification (Al.1.4) before 
verifying the metadata (Al.1.2). 
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Department (MARS OV-4) 

Role (MARS OV-2) 

Description (MARS OV-5a) 

Office of the Chief Financial 
Officer 

MSFC RNO 

Updates the metadata (Al.1.3) or submits questions for clarification (Al.1.4) before 
verifying the metadata (Al.1.2). 

Shuttle Propulsion Office 

MSFC Application 
Portfolio Manager 

Coordinates with the stakeholders to verify (Al.2.1) or update (Al.2.2) the metadata. 
Returns the verified metadata to the MSFC EA (Al.2.3). Role also reviews the initial 
analysis about the applications that are being recommendation for decommission 
(A2.3). 

Ares Project Office 

MSFC Application 
Portfolio Manager 

Coordinates with the stakeholders to verify (Al.2.1) or update (Al.2.2) the metadata. 
Returns the verified metadata to the MSFC EA (Al.2.3). Role also reviews the initial 
analysis about the applications that are being recommendation for decommission 
(A2.3). 

Science and Mission Systems 
Office 

MSFC Application 
Portfolio Manager 

Coordinates with the stakeholders to verify (Al.2.1) or update (Al.2.2) the metadata. 
Returns the verified metadata to the MSFC EA (Al.2.3). Role also reviews the initial 
analysis about the applications that are being recommendation for decommission 
(A2.3). 

Engineering Directorate 

MSFC Application 
Portfolio Manager 

Coordinates with the stakeholders to verify (Al.2.1) or update (Al.2.2) the metadata. 
Returns the verified metadata to the MSFC EA (Al.2.3). Role also reviews the initial 
analysis about the applications that are being recommendation for decommission 
(A2.3). 

Safety and Mission Assurance 
Directorate 

MSFC Application 
Portfolio Manager 

Coordinates with the stakeholders to verify (Al.2.1) or update (Al.2.2) the metadata. 
Returns the verified metadata to the MSFC EA (Al.2.3). Role also reviews the initial 
analysis about the applications that are being recommendation for decommission 
(A2.3). 


Figure 22 MARS OV-4 Organization, Role, and Description Table 


See Figure MARS OV-4 Organization Relationship Chart below for the MSFC Organizational Relationship Chart and the depiction 
of the key operational performers involved within the MARS architecture. The MARS OV-2 view can be found in section labeled 
OV-2 Operational Resource Flow Description View and the section labeled OV-5a Operational Activity Decomposition Tree View 
contains the details for the activities. 

18.2.4 View Integration 

The authors overlaid the MARS OV-4 on the MARS OV-2 to depict that roles are exchanging information within the MARS 
Architecture. The overlay resulted in the new construction of both the functional activities along with the organizational physical 
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characteristics that are performing the activities. This overlay of activities and roles to organization allow the MSFC organization 
to better understand how their organization will interact as part of the new application scoring capability being introduced as 
part of this project. 

The authors also integrated the MARS OV-4 with the MARS CV-5. The MARS CV-5 shows the organization along the Y axis and 
the detailed capabilities defined in the MARS CV-2 along the X axis. Within the cell intersection of the X and Y axis, the authors 
color coded the cell indicating which MARS CV-2 score will be integrated into that organization. Additional details about the use 
of the MARS CV-5 can be found in section labeled CV-5: Capability to Organizational Development Mapping View. For 
additional details on the use of the MARS CV-2 see section labeled CV-2: Capability Taxonomy View. 

Due to the tight integration between the MARS views, the architecture reviewer can trace the performers depicted in the MARS 
OV-4, back to their operational roles depicted in the MARS OV-2, back to the activities depicted in the MARS OV-5a. See section 
labeled OV-2 Operational Resource Flow Description View operational roles and see section labeled OV-5a Operational Activity 
Decomposition Tree View contains the details for the operational role activities. 

Finally, the authors integrated the MARS OV-4 with the MARS SV-1. The authors depicted the organization roles on the view 
showing the system resource that the operational performer is using, and how the system resources interact with other systems 
contained within the MARS Architecture. For additional details on the use of the MARS SV-1, see section labeled SV-1 Systems 
Interface Description View. 

18.2.5 Stakeholder Questions Addressed 

• SQ-03 How can MSFC determine the extent of underused, unused, low business value, and/or low technology value 
applications in its application portfolio? 

• SQ-04 How can MSFC determine the extent of overlapping functionality within its application portfolio? 

• SQ-05 How can MSFC determine the cost to maintain an application in its application portfolio versus what it costs to retire 
or decommission it? 

• SQ-06 How can MSFC determine the extent of applications in its application portfolio that are still active past their target 
retirement dates? 
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Figure 23 MARS OV-4 Organization Relationship Chart 
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19 CV-2 Capability Taxonomy View 

19.1 DoDAF-Described CV-2 


19.1.1 Description 

The CV-2 Capability Taxonomy view presents a hierarchy of capabilities. The view specifies the capabilities that are referenced 
throughout the architecture description. The CV-2 does not specify how a capability is to be implemented but depicts a 
hierarchy of capabilities, with the most general at the root and most specific at the leaves. At the leaf-level, capabilities have a 
measure specified, along with an environmental condition for the measure. The CV-2 is used to capture and organize the 
capability functions - required for the vision set out in the CV-1 Vision. 

The CV-2 has no mandated structure although the architectural data must be able to support the representation of a 
structured/hierarchal list. This structure may be delivered using textual, tabular, or graphical methods. 

19.1.2 Purpose 

The CV-2 purpose is to support the following: 

• Identification of capability requirements 

• Capability planning (capability taxonomy) 

• Codifying required capability elements 

• Capability audit 

• Capability gap analysis 

• Source for the derivation of cohesive sets of user requirements 

• Providing reference capabilities for architectures 

19.1.3 Audience 

The CV-2 audience includes: 

• Architecture sponsors 

• Architecture stakeholders 

• Architecture development team 
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19.2 MARS Architecture CV-2 

19.2.1 Tailoring Applied 

The authors did not tailor the MARS CV-2 (since DoDAF does not prescribe a format for the view) but the authors did include 
environmental factors associated with MSFC for context. 

19.2.2 Viewpoint 

The viewpoint of the MARS CV-2 is the M EAAC. 

19.2.3 View Discussion 

The MARS CV-2 depicts the capability hierarchy in terms of three score sub-types: business, retirement, and technology. The 
MARS CV-2 includes score capability attributes, which represent the measures used to produce MSFC application scores. The 
authors plan to describe these measures in detail when the MARS AV-2 is updated in Phase 2. 

19.2.4 View Integration 

The MARS CV-2 depicts the decomposition of the MARS CV-1 Score Application capability. The MARS CV-2 was used to define 
the business score, retirement score, and technology score measures that were depicted along the X axis of the MARS CV-5. This 
allows the integration of the capability vision, the measurement scores, and the MSFC Organizations that are participating within 
the MARS Architecture to provide the capability. 

19.2.5 Stakeholder Questions Addressed 

• SQ-01 How can MSFC consistently evaluate the relative importance and performance of steady-state applications? 

• SQ-02 How can MSFC reduce its overall application portfolio base, and thereby reduce future data center and infrastructure 
costs? 

• SQ-03 How can MSFC determine the extent of underused, unused, low business value, and/or low technology value 
applications in its application portfolio? 

• SQ-04 How can MSFC determine the extent of overlapping functionality within its application portfolio? 

• SQ-05 How can MSFC determine the cost to maintain an application in its application portfolio versus what it costs to retire 
or decommission it? 

• SQ-06 How can MSFC determine the extent of applications in its application portfolio that are still active past their target 
retirement dates? 
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Figure 24 MARS CV-2 Capability Taxonomy 
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20 CV-5 Capability to Organizational Development Mapping View 

20.1.1 DoDAF-Described CV-5 

20.1.2 Description 

The CV-5 Capability to Organizational Development Mapping view addresses the fulfillment of capability requirements. The CV-5 
is used to support the capability management process; in particular, to assist the planning and fielding of an architecture. The 
CV-5 shows deployment of capabilities to specific organizations. If a particular capability is to be used by a specific organization 
during that phase, it should be shown on the CV-5, mapped to the organization. The CV-5 also shows interactions between them 
by indicating a reference point where the capability and the organization touch. 

The CV-5 is usually based on a tabular representation, with the appropriate organizational structure represented by one axis, 
and the capabilities by the other axis. Graphical objects representing capabilities or resources can be placed in the relevant 
positions (intersections) relative to these axes. 

20.1.3 Purpose 

The CV-5 purpose is to support the following: 

• Fielding planning 

• Capability integration planning 

• Capability options analysis 

• Capability redundancy/overlap/gap analysis 

• Identification of deployment level shortfalls 

20.1.4 Audience 

The CV-5 audience includes: 

• Architecture sponsors 

• Architecture stakeholders 

• Architecture development team 
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20.2 MARS Architecture CV-5 

20.2.1 Tailoring Applied 

The authors tailored the MARS CV-5 as follows: 

• Included an X axis depicting the scoring indicators that are used to produce the three scores that comprise the new sub-capabilities: 

o Business Score 
o Retirement Score 
o Technology Score 

• Mapped the organizational role (performer) that participated in A1 Verify Metadata, A2 Analyze Data and A3 Approve Retirement 
top level MARS OV-5a activities. 

• Added color coding to indicate which capability measure applies to the organizational performer implementing the capability. 

20.2.2 Viewpoint 

The viewpoint of the MARS CV-5 is the M EAAC. 

20.2.3 View Discussion 

The MARS CV-5 depicts the MSFC Organizations that are stakeholders within the MARS Architecture along the Y axis and the 
measures that produce the Score Application capability (Business Score, Retirement Score, and Technical Score) along the X axis. 

At the intersection of the organization and the measure, the authors color coded the capability that the MSFC Organization will 
produce and combine with the other scoring measures on the MARS CV-2. This allows the MARS Architecture to apply a scoring 
measure to a group of applications to recommend low business and low technology value applications for retirement. 

See figure labeled MARS CV-5 Capability to Organizational Mapping below to review the integration of the capabilities that have 
been decomposed into the MARS CV-2 view and the MSFC Organization that participate in the production of the capability. 

20.2.4 View Integration 

The MARS CV-5 was integrated with the MARS CV-2 by detailing the CV-2 scores that the measures will produce and the MARS 
OV-4 view that depicts the MSFC Organization and MSFCs location within the NASA enterprise organization. 
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20.2.5 Stakeholder Questions Addressed 

• SQ-03 How can MSFC determine the extent of underused, unused, low business value, and/or low technology value 
applications in its application portfolio? 

• SQ-04 How can MSFC determine the extent of overlapping functionality within its application portfolio? 

• SQ-05 How can MSFC determine the cost to maintain an application in its application portfolio versus what it costs to retire 
or decommission it? 

• SQ-06 How can MSFC determine the extent of applications in its application portfolio that are still active past their target 
retirement dates? 
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21 StdV-1 Standards Profile 

21.1 DoDAF-described StdV-1 

21.1.1 Description 

The StdV-1 Standards Profile defines the technical, operational, and business standards, guidance, and policy applicable to the 
architecture being described. The StdV-1 also documents the policies and standards that apply to the operational or business 
context. The DoD Information Technology Standards and Profile Registry (DISR) is an architecture resource for technical 
standards that can be used in the generation of the StdV-1. 

In DoDAF V2.0, the StdV-1 is generalized to incorporate all applicable standards for architecture. It collects the various systems 
standards rules that implement and sometimes constrain the choices that can be made in the design and implementation of 
architecture. 

21.1.2 Purpose 

The StdV-1 purpose is to delineate standards, rules, and conventions that apply to architecture implementations. It provides 
information to guide architecture implementers in making standards choices. And, it guides procurement in requirements that 
mandate standards use. 

21.1.3 Audience 

The StdV-1 audience includes: 

• MARS Architecture performers and key stakeholders 

• System implementers 

• Program managers 

21.2 MARS Architecture StdV-1 

21.2.1 Tailoring Applied 

Because the MARS Architecture does not focus on a Department of Defense enterprise or on a technology, the authors tailored 
the MARS StdV-1 so it includes both guidance and standards pertinent to the Enterprise Architecture Practice at MSFC. The 
authors also included guidance associated with IT investments and portfolio management. The authors did not incorporate 
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references to service areas contained in the DoD Information Technology Standards and Profile Registry (DISR) into the MARS 
StdV-1 because it did not seem "fit for purpose" to the MSFC enterprise. 


21.2.2 Viewpoint 

The viewpoint of the MARS StdV-1 is the MEAAC. 


21.2.3 View Discussion 

The MARS StdV-1 lists guidance and standards applicable to the MARS Architecture. This version of the MARS StdV-1 is not 
intended as an exhaustive or complete list of sources; the list is provided to support Phase 1 of the MARS Architecture and will 
be modified as the project progresses. 

21.2.4 View Integration 

The MARS StdV-1 is integrated with the MARS Architecture operational and system viewpoints, in particular MARS OV-5b, OV-2, 
OV-3, and SV-1. 

21.2.5 Stakeholder Questions Addressed 

All stakeholders may refer to the MARS StdV-1 for information about the guidance and standards that apply to the MARS 
Architecture. The MARS StdV-1 was not developed to address specific stakeholder questions but to address the business policy, 
guidance, and technical standards that apply to and constrain the MARS Architecture. 
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Figure 26 MARS Architecture StdV-1 Standards Profile 


Date: 12 June 2010 MARS Architecture StdV-1 Standards Profile MARS 12 

Guidance, Policy, and Standards 

Description 

Clinger-Cohen Act ofl996. Public Law 104-106, section 5125, 110 
Stat. 684 (1996) 

Recognizes the need for Federal Agencies to improve the way they select and 
manage IT resources and states, "information technology architecture, with respect 
to an executive agency, means an integrated framework for evolving or maintaining 
IT and acquiring new IT to achieve the agency's strategic goals and information 
resources management goals." Chief Information Officers are assigned the 
responsibility for "developing, maintaining, and facilitating the implementation of a 
sound and integrated IT architecture for the executive agency" 

E-Government Act of 2002 

Calls for the development of Enterprise Architecture to aid in enhancing the 
management and promotion of electronic government services and processes. 

Federal Information Processing Standard (FIPS) Publication 183 
Integration Definition For Function Modeling (IDEFO) 

This standard describes the modeling language (syntax and semantics) which 
supports the IDEFO technique for developing structured graphical representations of 
a system or subject area. Use of this standard permits the construction of IDEFO 
models comprising system functions (actions, processes, and operations), functional 
relationships, and the data and objects that support systems analysis and design, 
enterprise analysis, and business process re-engineering. 

Federal Information Processing Standard (FIPS) Publication 184 
Integration Definition For Information Modeling (IDEF1X) 

This standard describes the IDEF1X modeling language (semantics and syntax) and 
associated rules and techniques, for developing a logical model of data. IDEF1X is 
used to produce information models which represent the structure and semantics of 
information within an enterprise. 

General Accounting Office Enterprise Architecture Management 
Maturity Framework (EAMMF) 

"Outlines the steps toward achieving a stable and mature process for managing the 
development, maintenance, and implementation of enterprise architecture." Using 
the EAMMF allows managers to determine what steps are needed for improving 
architecture management. 

MARS Architecture Practicum Report, rev-3 12 June 2010 Page 98 



Date: 12 June 2010 MARS Architecture StdV-1 Standards Profile MARS 12 

Guidance, Policy, and Standards 

Description 

Government Accounting Office (GAO) Information Technology 
Investment Management (ITIM): A Framework for Assessing and 
Improving Process Maturity 

The ITIM framework is a maturity model composed of five progressive stages of 
maturity that an agency can achieve in its IT investment management capabilities. 
These maturity stages are cumulative; that is, in order to attain a higher stage of 
maturity, the agency must have institutionalized all of the requirements for that 
stage in addition to those for all of the lower stages. The framework can be used 
both to assess the maturity of an agency's investment management processes and 
as a tool for organizational improvement. 

The latest ITIM incorporates comments from earlier drafts; GAO's experiences in 
evaluating several agencies' implementations of investment management processes 
and the lessons learned by these agencies; and the importance of enterprise 
architecture (EA) as a critical frame of reference in making IT investment decisions. 

IMSB-Plan-2800.1: MSFC Center IT Governance and 
Organizational Alignment Plan 

Each NASA Center was tasked with producing a plan that describes how it will 
implement IT governance and organizational realignment under the Agency IT 
management strategies identified in the December 2007 release of the Agency's 
"Strategy for Improving Information Technology (IT) Management at NASA" by the 
NASA Office of the Chief Information Officer. 

This document outlines the approach that MSFC will use to implement the key 
strategies. 

ISO/IEC 9075-2:2008 

ISO/IEC 9075 defines the SQL language. The scope of the SQL language is the 
definition of data structure and the operations on data stored in that structure. 
ISO/IEC 9075-1:2008, ISO/IEC 9075-2:2008 and ISO/IEC 9075-11:2008 encompass 
the minimum requirements of the language. Other parts define extensions. 

ISO/IEC 9075-2:2008 defines the data structures and basic operations on SQL-data. 
It provides functional capabilities for creating, accessing, maintaining, controlling, 
and protecting SQL-data. Both static and dynamic variants of the language are 
proved. In addition to direct invocation, bindings are provided for the programming 
languages Ada, C, COBOL, Fortran, M, Pascal, and PL/I. 
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Date: 12 June 2010 MARS Architecture StdV-1 Standards Profile MARS 12 

Guidance, Policy, and Standards 

Description 

MPD 2800.1: Management of Information Technology Systems 
and Services at MSFC 

The purpose of this document is to implement the NASA strategic policy for 
managing information technology and to establish organizational authority and 
responsibilities that govern the acquisition, management and use of IT products, 
services, and support contracts at MSFC. 

MSFC Enterprise Architecture Management Plan 

This document identifies and describes the objectives, performance requirements, 
resources, controls, and supporting plans and procedures required to satisfy goals of 
the MSFC Enterprise Architecture (EA). This document also provides a structure for 
MSFC EA support to Center EA Management, collaboration on Agency-level EA 
activities, NASA Mission Directorate alignment, and Center EA development. 

NPD 1001.0: NASA Strategic Plan 

This document describes the strategic goals of NASA. Every activity that an EA 
performs should be aligned with a NASA strategic goal, thus an understanding of the 
goals is needed. 

NPD 2800. IB: Managing Information Technology 

This document provides the policy for ensuring that information technology and 
information resources are acquired and managed in a manner that implements the 
policies, procedures, and priorities of the Agency and the Federal Government. 

NPR 2800. IB: Managing Information Technology 

This document establishes requirements and responsibilities for information 
technology management relative to the policy set forth in NPD 2800. IB. 

NPR 7120.7: NASA Information Technology and Institutional 
Infrastructure Program and Project Management Requirements 

This document establishes the requirements by which NASA will formulate and 
execute information technology and institutional infrastructure programs and 
projects, consistent with the governance model contained in the NASA Governance 
and Strategic Management Handbook (NPD 1000.0). 

Office of Management and Budget (OMB) Circular A-130 

"Establishes policy for the management of Federal information resources'^ and calls 
for the use of Enterprise Architectures to support capital planning and investment 
control processes. Includes implementation principles and guidelines for creating 
and maintaining Enterprise Architectures. 
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Date: 12 June 2010 MARS Architecture StdV-1 Standards Profile MARS 12 

Guidance, Policy, and Standards 

Description 

OMB Enterprise Architecture Assessment Framework (EAAF) 

Serves as the basis for enterprise architecture maturity assessments. Compliance 
with the EAAF ensures that enterprise architectures are advanced and appropriately 
developed to improve the performance of information resource management and IT 
investment decision making. 

OMB Federal Enterprise Architecture Reference Models (FEA RM) 

Facilitates cross-agency analysis and the identification of duplicative investments, 
gaps, and opportunities for collaboration within and across Federal Agencies. 
Alignment with the reference models ensures that important elements of the FEA 
are described in a common and consistent way. The Dodd Enterprise Architecture 
Reference Models are aligned with the FEA RM. 

RFC 1831 Remote Procedure Call Protocol Version 2 - August 
1995 

This document describes the ONC Remote Procedure Call (ONC RPC Version 2) 
protocol as it is currently deployed and accepted. "ONC'stands for "Open Network 
Computing." 

RFC 2060 Internet Message Access Protocol - Version 4revl 
Email IMAP 

The Internet Message Access Protocol, Version 4revl (IMAP4revl) allows a client to 
access and manipulate electronic mail messages on a server. IMAP4revl permits 
manipulation of remote message folders, called "mailboxes", in a way that is 
functionally equivalent to local mailboxes. IMAP4revl also provides the capability 
for an offline client to resynchronize with the server. 

IMAP4revl includes operations for creating, deleting, and renaming mailboxes; 
checking for new messages; permanently removing messages; setting and clearing 
flags; [RFC-822] and [MIME-IMB] parsing; searching; and selective fetching of 
message attributes, texts, and portions thereof. Messages in IMAP4revl are 
accessed by the use of numbers. These numbers are either message sequence 
numbers or unique identifiers. 
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Date: 12 June 2010 MARS Architecture StdV-1 Standards Profile MARS 12 

Guidance, Policy, and Standards 

Description 

RFC 2616 Hypertext Transfer Protocol - HTTP/1.1 

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for 
distributed, collaborative, hypermedia information systems. It is a generic, stateless, 
protocol which can be used for many tasks beyond its use for hypertext, such as 
name servers and distributed object management systems, through extension of its 
request methods, error codes and headers. A feature of HTTP is the typing and 
negotiation of data representation, allowing systems to be built independently of 
the data being transferred. 

HTTP has been in use by the World-Wide Web global information initiative since 
1990. This specification defines the protocol referred to as "HTTP/1.1", and is an 
update to RFC 2068. 
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22 AV-2 Integrated Dictionary 

22.1 DoDAF-Described AV-2 

22.1.1 Description 

The AV-2 Integrated Dictionary contains definitions of terms used in the architecture. It consists of textual definitions in the form 
of a glossary, a repository of architecture data, their taxonomies, and their metadata - including metadata for tailored views 
associated with the architecture views developed. Metadata are the architecture data types, possibly expressed in the form of a 
physical schema. (In this document, architecture data types are referred to as architecture data elements.) 

22.1.2 Purpose 

The AV-2 purpose is to: 

• Provide a central repository for data and metadata 

• Consolidate multiple viewpoint definitions 

• Remove ambiguity from the architecture description and provide a common language for communicating with stakeholders 

• Promote integration, aggregation, and semantic intersections 

22.1.3 Audience 

The AV-2 audience includes: 

• Architecture view users 

• Architecture view reviewers 

• Data administrators 

• Architecture sponsors 

• Architecture participants 

• Architecture stakeholders 

• Architecture development team 

• Architecture repositories 

• Enterprise repository managers 
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22.2 MARS Architecture AV-2 

22.2.1 Tailoring Applied 

The authors did not tailor the MARS AV-2. 

22.2.2 Viewpoint 

The viewpoint of the MARS AV-2 is the MEAAC. 

22.2.3 View Discussion 

The MARS AV-2 contains definitions of terms used in the MARS Architecture. It includes full and abbreviated term names, text 
definitions, sources (where applicable), architecture elements, and cross-references to architecture viewpoints where used. 

The authors constrained the scope of the integrated dictionary for Phase 1 of the project to those terms deemed most essential 
for audience interpretation of the viewpoints and architecture descriptions. The integrated dictionary will mature as the MARS 
Architecture project progresses. 

22.2.4 View Integration 

This version of the MARS AV-2 is a working draft and is included for representative layout and expected content only. The 
authors will walk through each viewpoint to extract terms and metadata to ensure accuracy, consistency, and completeness 
across the MARS Architecture. 

22.2.5 Stakeholder Questions Addressed 

All stakeholders may refer to the MARS AV-2 for information about the MARS Architecture. The MARS AV-2 was not developed 
to address specific stakeholder questions but to facilitate consistent and clear interpretation of MARS Architecture terminology, 
data elements, and associated cross-referencing. 
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Figure 27 MARS Architecture AV-2 Integrated Dictionary 

Date: 12 June 2010 


MARS Architecture AV-2: Integrated Dictionary 


MARS 13 

Term 

Abbreviation or 
Acronym 

Definition 

Role in Architecture 

Views Where 
Referenced 

Activity 

A 

To be defined in Phase 2. 

Activity 

OV-2, OV-3, OV-5a, 
OV-5b, SV-1 

Analysis 

none 

To be defined in Phase 2. 

Activity 

CV-1, OV-2, OV-3, 
OV-5a, OV-5b, SV-1 

Application 

none 

The use of information resources (information and 
information technology) to satisfy a specific set of user 
requirements (reference OMB A-130). Also, a set of 
computer commands, instructions, and procedures used 
to cause a computer to process a specific set of 
information. Applications do not include operating 
systems, generic utilities, or similar software that is 
normally referred to as "system software. 

(Source: MPD2800.1D , Management of Information 
Technology Systems and Services) 

System 

All 

Application Metadata 

none 

To be defined in Phase 2. 

Resource 

OV-l, OV-2, OV-3, 
OV-5a, OV-5b, SV-1 

Application Portfolio 

none 

See definition for portfolio. 

Resource 

AV-1, CV-1, OV-l, OV-2, 
OV-3, OV-5a, OV-5b, 
SV-1 

Application Portfolio 
Management 

MSFC APM 

The centralized management of one or more portfolios, 
which includes identifying, prioritizing, authorizing, 
managing, and controlling projects, programs and other 
related work, to achieve specific strategic business 
objectives. 

(Source: Practice Standard for Work Breakdown 
Structures - Second Edition) 

Process 

AV-1, CV-1, OV-l 
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MARS Architecture AV-2: Integrated Dictionary 


MARS 13 

Term 

Abbreviation or 
Acronym 

Definition 

Role in Architecture 

Views Where 
Referenced 

Application Portfolio 
Management System 

MSFCAPMS 

The application inventory management system that 
supports the MSFC Application Portfolio Management 
(APM) process. The system allows authorized users to 
enter data about applications and to map applications to 
Federal Enterprise Architecture (FEA)-based Reference 
Models and MSFC-defined Application Portfolios. The 
system also provides analysis and reporting tools. 

System 

OV-1, OV-3, 

OV-5a, OV-5b, SV-1 

Assessment 

none 

To be defined in Phase 2. 

Activity 

CV-l, OV-2, OV-3, 
OV-5a, OV-5b 

Capability 

none 

To be defined in Phase 2. 

Capability 

AV-1, CV-l, CV-2, CV-5 

Cost of Operations and 
Maintenance (O&M) 
Measure 

none 

To be defined in Phase 2. 

Resource 

AV-1, CV-2, CV-5 

Data 

none 

To be defined in Phase 2. 

Data 

OV-5b 

Desired Effect 

none 

To be defined in Phase 2. 

Desired Effect 

CV-l, CV-2 

Frequency of Use 
Measure 

none 

To be defined in Phase 2. 

Resource 

AV-1, CV-2, CV-5 

Guidance 

none 

To be defined in Phase 2. 

Guidance 

OV-5a, OV-5b, StdV-1 

Hypertext Transfer 
Protocol 

HTTP 

To be defined in Phase 2. 

System Function 

SV-1 

Information Exchange 

IE 

To be defined in Phase 2. 

Resource Flow 

OV-2, OV-3, OV-5a, 
OV-5b 

Measure 

none 

To be defined in Phase 2. 

Measure 

CV-2, CV-5 

Mission Alignment 
Measure 

none 

To be defined in Phase 2. 

Resource 

AV-1, CV-2, CV-5 
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Date: 12 June 2010 


MARS Architecture AV-2: Integrated Dictionary 


MARS 13 

Term 

Abbreviation or 
Acronym 

Definition 

Role in Architecture 

Views Where 
Referenced 

MSFC Application 
Portfolio Manager 

none 

The person who serves as the primary point of contact for 
each of the defined IT portfolios, integrating 
requirements across organizations and 
projects/programs. The Portfolio Manager maintains 
visibility of existing investments and proposals for new 
investments across the portfolio. 

(Source: MPD2800.1D , Management of Information 
Technology Systems and Services at MSFC) 

Performer, Stakeholder 

AV-1, CV-5, OV-1, OV-2, 
OV-3, OV-4, OV-5a, 
OV-5b, SV-1 

MSFC Chief Information 
Officer 

MSFC CIO 

The person responsible for the overall strategic direction, 
management, implementation, usability and performance 
of information and computer technologies at MSFC. 
(Source: MPD2800.1D , Management of Information 
Technology Systems and Services at MSFC) 

Performer, Stakeholder 

AV-1, OV-1, OV-2, OV-3, 
OV-4, OV-5a, OV-5b, 
SV-1 

MSFC Enterprise 
Architect 

MSFC EA 

The person who analyzes and documents the MSFC IT 
applications, business, and technology infrastructure in 
its current and future states, which serves to help 
integrate over-arching MSFC strategy, business, and 
technology perspectives, project objectives, and high- 
level performance goals. 

(Source: MSFC Enterprise Architecture Management Plan) 

Performer, Stakeholder 

AV-1, CV-5, OV-1, 
OV-2, OV-3, OV-4, 
OV-5a, OV-5b, SV-1 

MSFC Enterprise 
Architecture Advisory 
Committee (MEAAC) 

MEAAC 

The group that directs, oversees, and approves the MSFC 
enterprise architecture design and operating 
configurations that affect MSFC IT investments in the 
following MSFC IT portfolios: Engineering applications, 
Science applications, Project Management applications, 
Business Management applications, IT Infrastructure 
applications, and IT Infrastructure Services. The MEAAC 
reviews, approves, and controls changes to the baseline 
configuration of the MSFC enterprise architecture. 
(Source: MPD2800.1D, Management of Information 
Technology Systems and Services a MSFC) 

Performer, Stakeholder 

AV-1, OV-1, OV-2, OV-3, 
OV-5a, OV-5b, SV-1 
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MARS Architecture AV-2: Integrated Dictionary 


MARS 13 

Term 

Abbreviation or 
Acronym 

Definition 

Role in Architecture 

Views Where 
Referenced 

MSFC Planning, Policy, 
and Integration Office 

MSFC PP&IO 

The organization that provides strategic integration, 
policy planning, and Knowledge Management services for 
MSFC. This includes: 

• Continuous Risk Management 

• Customer Requirements Analysis 

• Customer Satisfaction and Surveys 

• Customer Service Requests 

• Customer Support Center 

• Enterprise Architecture 

• Innovation Management 

• Integrated Communications Planning 

• IT Governance 

• IT Policy 

• IT Portfolio Management 

• Organizational Scorecard 

• Project Management 

• Directives Management 

• Records Management 

• Forms Management 

(Source: MSFC Office of the CIO internal web site) 

Stakeholder 

AV-1, CV-5, OV-1, OV-4 

MSFC Portfolio Data 
Store 

MSFC Portfolio DS 

The database in which data about registered MSFC 
applications resides. 

System 

OV-2, OV-3, OV-5a, 
OV-5b, SV-1 

MSFC Portfolio DS 
Application Server 

none 

To be defined in Phase 2. 

System 

SV-1 

MSFC Portfolio DS 
Database Server 

none 

To be defined in Phase 2. 

System 

SV-1 
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MARS Architecture AV-2: Integrated Dictionary 


MARS 13 

Term 

Abbreviation or 
Acronym 

Definition 

Role in Architecture 

Views Where 
Referenced 

MSFC Portfolio DS Web 
Server 

none 

To be defined in Phase 2. 

System 

SV-1 

MSFC Stakeholders 

none 

To be defined in Phase 2. 

Performers, 

Stakeholders 

AV-1, CV-5, OV-1 

Network Use Measure 

none 

To be defined in Phase 2. 

Resource 

AV-1, CV-2, CV-5 

Number of Users 
Measure 

none 

To be defined in Phase 2. 

Resource 

AV-1, CV-2, CV-5 

Organization 

none 

To be defined in Phase 2. 

Organization 

CV-5, OV-4 

Performer 

none 

To be defined in Phase 2. 

Performer 

OV-l, OV-2, OV-3, 
OV-5b, SV-1 

Portfolio 

none 

A collection of projects or programs and other work that 
are grouped together to facilitate effective management 
of that work to meet strategic business objectives. The 
projects or programs of the portfolio may not necessarily 
be interdependent or directly related. 

(Source: Practice Standard for Work Breakdown 
Structures - Second Edition) 

Resource 

AV-1, CV-1, OV-1, OV-2, 
OV-3, OV-5a, OV-5b, 
SV-1 

Primary Functionality 
Measure 

none 

To be defined in Phase 2. 

Resource 

AV-1, CV-2, CV-5 

Remote Procedure Call 

RPC 

To be defined in Phase 2. 

System Function 

SV-1 

Resource 

none 

To be defined in Phase 2. 

Resource 

CV-5, OV-1, OV-2, OV-3, 
OV-4, OV-5b, SV-1 
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MARS 13 

Term 

Abbreviation or 
Acronym 

Definition 

Role in Architecture 

Views Where 
Referenced 

Responsible NASA 
Official 

RNO 

The NASA civil servant responsible for establishing the 
rules for appropriate use and protection of the 
data/information within a system. The system owner 
retains that responsibility even when the 
data/information is shared with other organizations. 
(Source: MSFC Application Inventory Module (AIM) online 
reference) 

Performer, Stakeholder 

AV-1, CV-5, OV-1, OV-2, 
OV-3, OV-5a, OV-5b, 
SV-1 

Retirement 

none 

To be defined in Phase 2. 

Process 

AV-1, CV-1, OV-1, OV-2, 
OV-3, OV-5a, OV-5b, 
SV-1 

Risk Rating Measure 

none 

To be defined in Phase 2. 

Resource 

AV-1, CV-2, CV-5 

Rules 

none 

To be defined in Phase 2. 

Rules 

future 

Scoring Measure 

none 

To be defined in Phase 2. 

Resource 

AV-1, CV-2, CV-5 

Security Compliance 
Measure 

none 

To be defined in Phase 2. 

Resource 

AV-1, CV-2, CV-5 

Standard 

none 

To be defined in Phase 2. 

Standard 

StdV-l 

Submittal 

none 

To be defined in Phase 2. 

Activity 

CV-1, OV-5a, OV-5b 

System 

none 

To be defined in Phase 2. 

System 

OV-3, SV-1 

System Exchange 

SE 

To be defined in Phase 2. 

System Function 

OV-2, OV-3, OV-5a, 
OV-5b 

Target Retirement Date 

none 

To be defined in Phase 2. 

Resource 

AV-1, CV-2, CV-5 

Verification 

none 

To be defined in Phase 2. 

Activity 

CV-1, OV-2, OV-3, OV- 
5a, OV-5b 

Vision 

none 

To be defined in Phase 2. 

Vision 

CV-1 
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MARS 13 

Term 

Abbreviation or 
Acronym 

Definition 

Role in Architecture 

Views Where 
Referenced 

Years In Use Measure 

none 

To be defined in Phase 2. 

Resource 

AV-1, CV-2, CV-5 


MARS Architecture Practicum Report, rev-3 


12 June 2010 


Page 111 


MARS Architecture Practicum Report, rev-3 


12 June 2010 


Page 112 


Part 3 
Reference 


MARS Architecture Practicum Report, rev-3 


12 June 2010 


Page 113 


MARS Architecture Practicum Report, rev-3 


12 June 2010 


Page 114 


24 Abbreviations and Acronyms 


Short Form 

Long Form 


APM 

Application Portfolio Management 


BCG 

Boston Consulting Group 


BRM 

Business Reference Model 


BSC 

Balanced Scorecard 


CDR 

Critical Design Review 


CIO 

Chief Information Officer 


DISR 

DoD Information Technology Standards and Profile Registry 


DM2 

DoDAF V2.0 Metamodel 


DoD 

Department of Defense 


DoDAF 

Department of Defense Architecture Framework 


EA 

Enterprise Architecture 


FEA 

Federal Enterprise Architecture 


FEAC 

Federal Enterprise Architecture Certification 


FEAF 

Federal Enterprise Architecture Framework 


GAO 

Government Accounting Office 


IT 

Information Technology 


ITIM 

Information Technology Investment Management 


MARS 

Marshall Application Realignment System 


MEAAC 

MSFC Enterprise Architecture Advisory Committee 
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Short Form 

Long Form 

MSFC 

Marshall Space Flight Center 

NASA 

National Aeronautics and Space Administration 

OMB 

Office of Management and Budget 

ORR 

Operational Readiness Review 

PDR 

Preliminary Design Review 

PP&IO 

Planning, Policy, and Integration Office 

RNO 

Responsible NASA Official 

SCR 

System Concept Review 

SQ 

Stakeholder Question 

SRR 

System Requirements Review 
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